[HN Gopher] Next Generation Out of Band Garbage Collection
       ___________________________________________________________________
        
       Next Generation Out of Band Garbage Collection
        
       Author : ksec
       Score  : 39 points
       Date   : 2024-11-02 19:57 UTC (3 hours ago)
        
 (HTM) web link (railsatscale.com)
 (TXT) w3m dump (railsatscale.com)
        
       | jeeyoungk wrote:
       | This is from several years ago (2017), but this has very similar
       | vibe as Instagram disabling Python GC - https://instagram-
       | engineering.com/dismissing-python-garbage-...
        
         | IshKebab wrote:
         | A 10% performance improvement on Python code is laughable. You
         | can get a 5000% performance improvement if you switch to a
         | better language.
        
       | hinkley wrote:
       | > 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.
        
         | byroot wrote:
         | 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.
        
       | henning wrote:
       | They 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.
        
         | jrockway wrote:
         | 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.)
        
       ___________________________________________________________________
       (page generated 2024-11-02 23:00 UTC)