[HN Gopher] An in-depth look at OCaml's new "best-fit" garbage c...
       ___________________________________________________________________
        
       An in-depth look at OCaml's new "best-fit" garbage collector
       strategy
        
       Author : testcross
       Score  : 89 points
       Date   : 2020-03-23 12:20 UTC (1 days ago)
        
 (HTM) web link (www.ocamlpro.com)
 (TXT) w3m dump (www.ocamlpro.com)
        
       | jjoonathan wrote:
       | Hell is other peoples' algorithmic choices. My GC-fu isn't high
       | level enough to comment on this one, but I just spent the last
       | two days suffering in dependency hell because someone thought it
       | would be a good idea to use a full-blown SAT solver for package
       | management. Grr.
        
         | ignoramous wrote:
         | > _...someone thought it would be a good idea to use a full-
         | blown SAT solver for package management_
         | 
         | Relevant: https://research.swtch.com/version-sat
        
           | jjoonathan wrote:
           | Right. SAT solvers are an excellent theoretical fit and a
           | terrible practical fit, at least at the current state of
           | tooling. Their runtime _does_ explode and the tooling _is
           | not_ any good at hinting as to why even when the explanation
           | turns out to be very simple. Debugging a black box that takes
           | an hour to evaluate each input is just.... ugggggghh.
           | 
           | In contrast, failing to dig up an exceedingly clever
           | combination of archaic package versions that technically fit
           | the user's specified requirements -- which is the "danger" of
           | using heuristics -- is such a small problem that it might
           | even be considered a feature, since said exceedingly clever
           | combinations are likely to be the result of poor version
           | definitions and unlikely to be what the user actually wants.
           | 
           | Of course, if the only people who can be persuaded to write
           | package managers are people doing research in the subject,
           | then I suppose letting them inflict their pet projects on us
           | is one way to compensate them for an otherwise thankless
           | task, and perhaps in that sense it's fair.
        
       | StreamBright wrote:
       | "Remember that whatever works best for you, it's still better
       | than having to malloc and free by hand. Happy allocating!"
       | 
       | Nice, they are saying exactly the same as those pesky game
       | developers.
       | 
       | https://www.youtube.com/watch?v=tK50z_gUpZI
        
         | pjmlp wrote:
         | Yeah, like Tim Sweeney.
         | 
         | "It's interesting that many games can afford a constant 10x
         | interpretation overhead for scripts, but not a spikey 1% for
         | garbage collection."
         | 
         | https://twitter.com/timsweeneyepic/status/880607734588211200
         | 
         | https://wiki.unrealengine.com/Garbage_Collection_Overview
         | 
         | Which was it again, the engine chosen by Nintendo, Microsoft
         | and Google as first party to their 3D APIs?
         | 
         | https://developer.nintendo.com/tools
         | 
         | https://docs.microsoft.com/en-us/windows/mixed-reality/unity...
         | 
         | https://stadia.dev/blog/unity-production-ready-support-for-s...
         | 
         | https://developer.android.com/games/develop/build-in-unity
         | 
         | The anti-GC crowd on the games industry, is no different than
         | the ones that fought adoption of C/Modula-2/Pascal over
         | Assembly, and then fought adoption of C++ and Objective-C over
         | C.
         | 
         | Eventually they will suck it up when the major platform owners
         | tell them it is time to move on.
        
         | k__ wrote:
         | What's their opinion on Rust?
        
       | twic wrote:
       | I'm not aware of any other industrial-strength GC using this
       | strategy. Are there any?
       | 
       | If not, is there something about OCaml that makes this strategy
       | more suitable than it is for other languages?
       | 
       | If not, is this a case of this being the best strategy they have
       | the resources to implement, rather than the best possible
       | strategy?
        
         | the8472 wrote:
         | I think the hotspot's CMS old gen allocator used best-fit
         | strategy since its collector didn't compact. But CMS has been
         | deprecated because newer, compacting low pause collectors have
         | taken over its use-cases while being less fragile.
        
           | hinkley wrote:
           | If memory serves, the new one uses an extra object header
           | that points from the old object to the new one during move
           | operations, and any reads of the old object get forwarded to
           | the new one.
           | 
           | I'm pretty sure that would have not performed well without
           | the aggressive prediction logic in modern processors.
           | 
           | Java 1's object accesses _always_ read through an indirect
           | pointer, but that went away in the name of performance,
           | either when Hotspot was introduced, or on the next round of
           | GC impromevents.
        
         | dfox wrote:
         | I feel that it is mostly about nobody else explicitly calling
         | the strategy best-fit. For example BIBOP-derived GCs (which for
         | purposes of this discussion includes BDW GC) are inherently
         | best(-ish)-fit and in fact traditional unix malloc is also
         | mostly best-fit.
        
       ___________________________________________________________________
       (page generated 2020-03-24 23:00 UTC)