This is fascinating.

The idea of mark/scavenge is pretty cool for page-based allocation and deallocation.

Also real-time or maybe latency-intolerant systems, which basically can't block for garbage collection. You could probably keep scavenging and stay ahead of things without impacting things in a black and white way.

▲

AtlasBarfed 7 months ago | parent [-]

This may be naive, but gc has now been around since the java days at mass scale (that is I'm calling java the first mass market GC computing system, just go with it for now) for about 30 years.

The big lie of GC is that you never need to worry about memory management. The insidious lie is that you have no control when you do need it

Rust went with a new extreme: no GC, but the compiler does a memory verification and a LOT of obscure complex notation and keywords

So ... I'm wondering if there is a happy medium, where you can have keywords that strongly hint to a GC how to manage memory (eg arena/permanent, thread group bound, local/young, etc) that will be easier than rust.

Maybe we could have multiple heaps defined (a big problem with GC heaps is the bigger they are the harder it is for the bigO of the management algorithms to scale, so nice they aren't linear bigO).

I'm thinking of something like Cassandra where tables and even subsections of tables don't need their bloom filters, commit logs, atc all intermingled in a single heap, to the great detriment of heao performance.

Instead, provide annotations to partition the heaps or run multiple heaps

Of course this is a massive complexity rabbit hole/slippery slide.

	▲	m463 7 months ago \| parent \| next [-]
		I remember a long time ago using the apache portable runtime and pool malloc was pretty interesting. I believe it probably was designed around web requests - which could disappear at any time. The idea was that you allocated a memory pool, and did all your mallocs within that pool. If there was a problem, you could easily clean up and free the entire pool. I think this idea could work really well the the memory system - a pool could be a number of underlying pages and gc would be easy, and letting go of the pages would be too.
	▲	funcDropShadow 7 months ago \| parent \| prev \| next [-]
		> Maybe we could have multiple heaps defined As far as I understand, Erlang has one heap per actor. The cost is that messages have to be serialized to pass from one actor to another. But it means there are lots of independent, often tiny heaps which don't need very complicated GCs.
	▲	jddj 7 months ago \| parent \| prev [-]
		Zig's allocators run along this line of thought