An in-depth look at OCaml’s new “best-fit” garbage collector strategy
1–10 of 43 posts
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#2"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.
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#3I'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?
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#4I'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?
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.
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#5I'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?
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.
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#6Hell 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.
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#7"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
What's their opinion on Rust?
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#8Hell 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.
> ...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
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#9I'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?
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.
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.
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#10"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
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.