> Which means your changes have to go through the Ruby team first. Any additional changes would also need to go through them …
I do want to pick on this specifically - people can and should be patching open source projects they depend on and deploying them to production (exactly as described in the article). Something being in the language vs in “user” code should be no barrier to improving it.
There's a pretty huge difference between implementing a performance optimization that works in your use case, and upstreaming that optimization to be generally usable.
The latter is often orders of magnitude more work, and the existing solution is probably chosen to be well suited in general.
Patching a dependency comes with significant downstream costs. You need to carry the patch forward to new upstream versions . This implies remembering that the dependency was patched, extracting a patch from the existing changed code, and reapplying the patch, fixing comflicts, recompiling the now special version of that dependency and running tests, checking/updating required license notices accordingly.
This is in essence another form of technical dept.
I don't work on YJIT but I _think_ i know the (or maybe an) answer to this. The code for a JIT'd ruby method isn't contiguous in one location in memory. When a ruby method is first compiled, a straightline path through the method is emitted , and branches are emitted as stub code. When the stub is hit, the incremental compilation of that branch then happens. I believe this is called "lazy basic block versioning".
When the stub is hit the code that gets generated is somewhere _else_ in executable memory, not contiguous with the original bit of the method. Because these "lazy basic blocks" are actually quite small, the bookkeeping involved in "where is the code for this ruby method" would actually be an appreciable fraction of the code size itself. Plus you then have to do more bookkeeping to make sure the method you want to GC isn't referred to by the generated code in another method.
Since low memory usage is an important YJIT goal, I guess this tradeoff isn't worth it.
Maybe someone who knows this better will come along and correct me :)
This is essentially what systemd-resolved with the nss-resolve NSS module is right? It’s possible to use /etc/nsswitch.conf to entirely disable the built-in DNS resolution in glibc if you want.
> a per-thread GIL with an explicit mode to share particular objects
This is like Ruby's Ractors and I haven't really seen that be super successful so far. The "Objects" that need to be shared are things like class definitions, etc.... there are a ton of subtle issues with objects that are being marked as sharable when they should really not be or vice versa.
The problem is that with perf the stack trace is collected by the kernel (when the interrupt from the performance counters fires), and the kernel doesn’t implement dwarf unwinding of user space code.
It _could_, but the kernel folks have made it pretty clear they don’t want to put any code related to dwarf in the kernel.
an interesting analogy: 1-to-1 email used to be considered private. actually, a lot of people still use it with an expectation of privacy (see: password resets sent over email, politicians regularly having their incriminating emails leaked, or good ol’ personal correspondence). but technically it’s never been all that private: most SMTP servers don’t mandate SSL, and even with SSL most email remains readable and indexed by Google.
i have no problem when the people i intended to reach save and index my email. yet i think i’m reasonable in being upset whenever i discover a new party i didn’t know/expect is doing it (e.g. NSA).
SMTP sniffing, SNI sniffing, DNS sniffing: these are all instances where ingesting “openly available” data is beneficial to the party doing it but costly to me (it limits my ability to speak freely with a consenting party without consequence).
fediverse is clearly split on this. some people have expectations based more in personal correspondence, and don’t want to end up in the same situation as email where the adversarial relations and negative externalities are just de-facto/accepted. others have expectations based in mass-media, where the further your comms travel the better. but for most users, they use the protocol for a mix of both, and that makes for a messy and difficult to reason about situation.
some of this is solvable with protocol upgrades. but that’s going to take a lot of time, and it’s not clear that every social norm even can be enforced technically.
I do want to pick on this specifically - people can and should be patching open source projects they depend on and deploying them to production (exactly as described in the article). Something being in the language vs in “user” code should be no barrier to improving it.
reply