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
An in-depth look at OCaml’s new “best-fit” garbage collector strategy
41–43 of 43 posts
Re: An in-depth look at OCaml’s new “best-fit” garbage collector strategy
#42Earlier 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…
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
#43Earlier 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…