The bigger problem is mutability. Any pointers into the bit-packed enum storage become invalid as soon as you change its type. To solve this you can either prohibit pointers into bit-packed enum storage, which is very limiting, or introduce immutability into the language. Immutability is particularly difficult to add to go, where default zero-values emerge in unexpected places (such as the spare capacity of slices and the default state of named return values)
Memory barriers don't force a flush of all CPU cache. They will enforce the ordering of memory operations issued before and after the barrier instruction, preserving the contents of the CPU's various caches.
Thanks for writing this. It takes a deep understanding to explain such complicated concepts in an accessible way. Reading it brought back fond memories of hacking on jailbreak projects deep into the night.
Go's internal linker is much faster than the system linker thanks to some go-specific optimizations. Go must fall back to the system linker whenever CGO is used.
If best effort is good enough and your use case doesn't require robustness, reading out of host /proc certainly works. Tracking execs with hooks in the kernel's internal exec mechanism with a separate indexing step at startup is worth the extra effort for use cases that do require accurate data, such as security observability.
It's not robust at all. Programs can and will exit before the userspace daemon is able to read from /proc. Malicious programs can even attribute their network activity to any program on the system they are able to exec by execing that program immediately afterwards or concurrently from another thread. One can properly track program paths/arguments by setting kprobes on the exec functions within the kernel and copying the data to a ring buffer read in userspace or by reading out of the task struct using bpf_probe_read_kernel.
This is what ETags are for. Upon a user's first visit the server should return an ETag uniquely representing the current version of the page. The browser will cache both the page and the tag. Upon subsequent page visits the browser will send an If-None-Match header containing the tag for the version of the page it has cached. The server should compare the incoming tag with the tag for the current version and return a "304 Not Modified" response if the tags match or a full response with the newer tag in the ETag header if they don't.
A benefit of storing the reference count in the high bits is that overflows will never corrupt the flag bits and can be detected using the processor's flags instead of requiring a separate check. I'm not sure if this property is used here.
That's likely due to amp-font, which will wait a certain amount of time for custom fonts to load before continuing with a fallback browser font (see: https://amp.dev/documentation/components/amp-font)
The code to run in the worker is passed as a string or a path, so no data can be captured. Data can be sent to the worker by posting messages, but the data is never shared—only copied. A limited set of types can be transferred to a worker, after which point they will become unusable in the parent.
Out of curiosity, what stopped you from setting the -install_name flag when you built the libraries you are bundling with your juicysfplugin plugin? That's the standard mechanism for building app-relative libraries and wasn't listed at all under "Alternatives to manually rewriting dynamic links"
Enabling source maps will have the source including type annotations show up in the web inspector, but the information isn't usable by the JavaScript VM to validate types at runtime. This is also necessary to preserve line and column information when debugging.