Live data from Hacker News

An in-depth look at OCaml’s new “best-fit” garbage collector strategy

ocamlpro.com

41–43 of 43 posts

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#41
post #39

Earlier quoted context omitted.

How does Rust deal with long-lived objects that cannot be block-scoped (or request-scoped, in the context of a server for example)? A typical example here would be a UI framework, where memory has to be managed for the window and its widgets, and then the entire application is suspended until the next event. The user can open and close windows in random orders, and so on. Perhaps some windows generate a lot of associ…

It seems like you want a reference-counted pointer: you get shared ownership, and the object is deleted when the last reference to the pointer is deleted. Similar to C++'s std::shared_ptr

Right, but then you take on a bunch of baggage you don’t have in a GC setting. For instance if you want to make zillions of these objects and delete them you are paying overhead for lots of allocations and deallocations made heavier by the reference counting. You pay time overhead for atomic increment/decrement, and if there are cyclic structures then you pay a big price in the code complexity to deal with them properly and not cause memory leaks.

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#42
post #39

Earlier quoted context omitted.

Great question. I am really hoping that the non-GC world is taking off with Rust.

How does Rust deal with long-lived objects that cannot be block-scoped (or request-scoped, in the context of a server for example)? A typical example here would be a UI framework, where memory has to be managed for the window and its widgets, and then the entire application is suspended until the next event. The user can open and close windows in random orders, and so on. Perhaps some windows generate a lot of associ…

> How does Rust deal with long-lived objects that cannot be block-scoped (or request-scoped, in the context of a server for example)?

The issue is not really the scope, the issue is how many owners the data needs to have. A variable that needs to live longer than a scope, but only has a single owner, can be directly returned from that scope. Once you have the need for multiple owners, the most straightforward answer is "reference count them," but it depends on your exact requirements.

> A typical example here would be a UI framework, where memory has to be managed for the window and its widgets, and then the entire application is suspended until the next event.

GTK heavily uses reference counting. People are also investigating what a "rust-native" UI toolkit would look like; taking strong influences from ECSes. It's an open question if those architectures end up better than refcounts.

Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy

#43
post #9

Earlier quoted context omitted.

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, eit…

They are two new GCs Shenandoah and ZGC. Indirect pointers or Brooks pointers has it is called were used in Shenandoah v1 to allow an application thread that perform a read to not move the object during the evacuation phase. This strategy has been removed in Shenandoah v2 to have a better throughput so now both read and write by the application move the object during the evacuation phase. ZGC has never used Brooks po…

I had to look up 'Brooks pointers'. For anyone else in this position, these two blog posts seem a good place to start: https://rkennke.wordpress.com/2013/10/23/shenandoah-gc-brook... , https://blog.plan99.net/modern-garbage-collection-part-2-1c8...
Post reply on HN