Next Generation Out of Band Garbage Collection
railsatscale.com
Next Generation Out of Band Garbage Collection
1–10 of 87 posts
Re: Next Generation Out of Band Garbage Collection
#2This is from several years ago (2017), but this has very similar vibe as Instagram disabling Python GC - https://instagram-engineering.com/dismissing-python-garbage-...
Re: Next Generation Out of Band Garbage Collection
#3[deleted]
Re: Next Generation Out of Band Garbage Collection
#4[deleted]
Re: Next Generation Out of Band Garbage Collection
#5> Ideally in a web application, aside from some in-memory caches, no object allocated as part of a request should survive longer than the request itself.
This is one of those areas where out of process caching wins. In process caching has a nasty habit of putting freshly created objects into collections that have survived for days or hours, creating writes in the old generation and back references from old to new.
Going out of process makes it someone else’s problem. And if it’s a compiled language with no or a better GC, all the better.
Re: Next Generation Out of Band Garbage Collection
#6They built a large codebase on a language that doesn't let you control memory, because that makes you "more productive". So just having Rails allocate a per-request arena that is asynchronously freed which would force the programmer not to have any objects that outlive the request, or just pre-allocating memory for a fixed amount of request handling per server instance, or whatever allocation behavior you want to do that is generally possible in C/C++/Zig/Rust/Odin/etc, requires hacking on the language itself. Which means your changes have to go through the Ruby team first. Any additional changes would also need to go through them, which increases the cost of change. Then there is a permanent layer of indirection between your GC callbacks and the semantics of what those callbacks do. Instead of just writing out the custom allocators you want, because that's impossible. How depressing.
Re: Next Generation Out of Band Garbage Collection
#7This is from several years ago (2017), but this has very similar vibe as Instagram disabling Python GC - https://instagram-engineering.com/dismissing-python-garbage-...
A 10% performance improvement on Python code is laughable. You can get a 5000% performance improvement if you switch to a better language.
Re: Next Generation Out of Band Garbage Collection
#8They built a large codebase on a language that doesn't let you control memory, because that makes you "more productive". So just having Rails allocate a per-request arena that is asynchronously freed which would force the programmer not to have any objects that outlive the request, or just pre-allocating memory for a fixed amount of request handling per server instance, or whatever allocation behavior you want to do…
I'm guessing that Zig, Rust, Oden, and "etc." didn't exist when they started the codebase. Now they need to keep moving in their imperfect state. I don't think anyone would start a large company on Ruby today. (They would on Python, though, which is equally unfortunate.)
Re: Next Generation Out of Band Garbage Collection
#9> Ideally in a web application, aside from some in-memory caches, no object allocated as part of a request should survive longer than the request itself. This is one of those areas where out of process caching wins. In process caching has a nasty habit of putting freshly created objects into collections that have survived for days or hours, creating writes in the old generation and back references from old to new. Go…
Author here.
Agreed. We have some facility for out of process caching (node local memcached), and I frequently have to argue with colleagues that it's generally preferable to in-process caching.
Re: Next Generation Out of Band Garbage Collection
#10They built a large codebase on a language that doesn't let you control memory, because that makes you "more productive". So just having Rails allocate a per-request arena that is asynchronously freed which would force the programmer not to have any objects that outlive the request, or just pre-allocating memory for a fixed amount of request handling per server instance, or whatever allocation behavior you want to do…
> 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.