[HN Gopher] Memory Management in Lobster
       ___________________________________________________________________
        
       Memory Management in Lobster
        
       Author : ingve
       Score  : 10 points
       Date   : 2021-07-30 13:11 UTC (9 hours ago)
        
 (HTM) web link (aardappel.github.io)
 (TXT) w3m dump (aardappel.github.io)
        
       | dragontamer wrote:
       | > The idea that just because "who is pointing to this object" is
       | a hard question we are not going to even try to track it, and
       | instead repeatedly scan large parts of the heap to recover that
       | information later, really makes me cringe.
       | 
       | Its cringy, but the more you think about it, the better it gets.
       | 
       | Only "Live Memory" costs you time in the scan. If there's a long-
       | lived object, you move the long-lived objects to the "old
       | generation" and now its not costing you any scan-time anymore.
       | 
       | As such, the "cost" of memory collection is in fact O(n), where n
       | is the amount of effective live-memory. And its somewhat easy to
       | keep "n" small in many cases.
       | 
       | Its one of those things that you think "Oh, that can't possibly
       | be efficient", but then any alternative (ex: ref-counts) end up
       | also being O(n) operations or worse (every single shared_ptr in
       | C++ needs to be ref_count++ and ref_count-- repeatedly as you
       | copy the values onto the stack... and those ref_count++ need to
       | be cohesive across threads. The ref_count-- needs to be
       | sequentially-consistent and 100% sure that its time to cleanup
       | when that ref_count does in fact reach 0)
       | 
       | Once you think of adding all of those thread-synchronization
       | primitives onto the shared ref_count variable to guarantee smooth
       | operation of ref_count-- (which happens to be 0)... all of a
       | sudden Java's generational collector leads to better
       | multithreaded performance in some scenarios.
       | 
       | ----------
       | 
       | > Ownership Analysis
       | 
       | Well, that's a nifty idea to say the least. To use static
       | compile-time analysis to reduce the costly ref_count++ and
       | ref_count-- operations (again: costly because they need to be
       | globally synchronized). So it sounds like the general gist is to
       | optimize away most of those ref_count++ and ref_count--
       | operations as possible, through some kind of compile-time magic.
       | 
       | EDIT: I guess its not magic since this "Lobster" is a new
       | programming language. So that analysis is in fact the point of
       | this discussion! I have my doubts that this analysis will prove
       | to be useful in highly dynamic situations (ex: Lisp lists, which
       | are linked-lists on steroids). But maybe that's not a problem. If
       | "most code" leads to the straightforward simple scenario, then
       | you get the benefits of the analysis in "most situations".
       | 
       | I don't think that most code use dynamic memory. Its just
       | difficult for most programmers to think of.
        
         | delusional wrote:
         | If your ok with stopping the world every once in a while I
         | don't think recounting needs to be globally synchronized. You
         | just stop the world, do the recount from an append only thread
         | safe log, and start the world again. No synchronization needed.
         | What you (arguably) save is a scan of all pointers to see if
         | they point to your object.
        
       ___________________________________________________________________
       (page generated 2021-07-30 23:01 UTC)