6 ms·

One thing I wish people in the PL/GC community would take more seriously is the idea of explicitly separate heaps or heap partitions. If it's a problem that pa

One thing I wish people in the PL/GC community would take more seriously is the idea of explicitly separate heaps or heap partitions. If it's a problem that pause times can be proportional to heap size with some approaches, then the problem can be alleviated by having more small heaps instead of one large. I've used this approach in my own code, including kernel code, to very good effect. Yet somehow the language features to support this properly have never existed in any language that I know of. At best we get heuristics to approximate it; more often, nothing.

liveoneggs 10y ago
erlang has this I think?
mike_hearn 10y ago
Research is done. Here is a tech talk on a form of GC integrated into the JVM where the user can annotate regions: http://www.oracle.com/technetwork/java/jvmls2015-wimmer-2637907.pdf http://www.oracle.com/technetwork/java/jvmls2015-wimmer-2637... https://www.youtube.com/watch?v=3JphI1Z0MTk&list=PLX8CzqL3ArzUo2dtMurvpUTAaujPMeuuU&index=12 https://www.youtube.com/watch?v=3JphI1Z0MTk&list=PLX8CzqL3Ar... The region markings are used as hints. Allocations are put into the region when possible and then the region is discarded at the end in one go, which is of course a well explored idea but this one is interesting in that you only scope out the regions and don't need to manually assign each allocation. Also allocations that naturally exist beyond the end of the region work properly without additional effort. One issue is that it's often quite hard to beat a properly tuned generational collector even with techniques that intuitively 'feel' right. As one example, Azul experimented with aggressive hardware-assisted stack allocation on their custom CPU and abandoned it because they found it didn't really beat well tuned generational collection.
- notacoward 10y ago
  Awesome, thanks!
- deleted 10y ago
  [deleted]
xenadu02 10y ago
The problem is you either need the equivalent of the Rust borrow-checker to validate that the partition boundaries are respected or the partitions are just hints which makes the scope of optimizations much smaller. It isn't GC but NeXTSTEP had allocation regions under this theory; that's where alloc:withZone: came from. In reality programmers mixed up the zones and there were way too many crashes as a result. Without some way to enforce the separation you just don't get much benefit.
dfox 10y ago
For traditionally GC'd languages you still need some way to track dependencies between separate heaps, which means that you end up with what is essentially overcomplicated generational GC. Handling inter-heap dependencies manually on the other hand gets you into space of hierarchical allocators (see samba's talloc or apache's apr_pool) which is something that still needs some kind of manual memory management.
pathsjs 10y ago
In Nim, each thread has its own heap :-)
gwbas1c 10y ago
.Net has AppDomains. You can't access heaps in one AppDomain from the other. I don't know if it's done so that GC can pause only one AppDomain; I always viewed it as more of a security and sandboxing feature.
bad_user 10y ago
If you need multiple heaps, you can already run multiple OS processes that communicate through message passing. Message passing is a little inefficient compared with shared memory concurrency, but you have to pick your poison.

liveoneggs 10y ago

erlang has this I think?

mike_hearn 10y ago

Research is done. Here is a tech talk on a form of GC integrated into the JVM where the user can annotate regions: http://www.oracle.com/technetwork/java/jvmls2015-wimmer-2637907.pdf http://www.oracle.com/technetwork/java/jvmls2015-wimmer-2637... https://www.youtube.com/watch?v=3JphI1Z0MTk&list=PLX8CzqL3ArzUo2dtMurvpUTAaujPMeuuU&index=12 https://www.youtube.com/watch?v=3JphI1Z0MTk&list=PLX8CzqL3Ar... The region markings are used as hints. Allocations are put into the region when possible and then the region is discarded at the end in one go, which is of course a well explored idea but this one is interesting in that you only scope out the regions and don't need to manually assign each allocation. Also allocations that naturally exist beyond the end of the region work properly without additional effort. One issue is that it's often quite hard to beat a properly tuned generational collector even with techniques that intuitively 'feel' right. As one example, Azul experimented with aggressive hardware-assisted stack allocation on their custom CPU and abandoned it because they found it didn't really beat well tuned generational collection.

notacoward 10y ago
Awesome, thanks!
deleted 10y ago
[deleted]

xenadu02 10y ago

The problem is you either need the equivalent of the Rust borrow-checker to validate that the partition boundaries are respected or the partitions are just hints which makes the scope of optimizations much smaller. It isn't GC but NeXTSTEP had allocation regions under this theory; that's where alloc:withZone: came from. In reality programmers mixed up the zones and there were way too many crashes as a result. Without some way to enforce the separation you just don't get much benefit.

dfox 10y ago

For traditionally GC'd languages you still need some way to track dependencies between separate heaps, which means that you end up with what is essentially overcomplicated generational GC. Handling inter-heap dependencies manually on the other hand gets you into space of hierarchical allocators (see samba's talloc or apache's apr_pool) which is something that still needs some kind of manual memory management.

pathsjs 10y ago

In Nim, each thread has its own heap :-)

gwbas1c 10y ago

.Net has AppDomains. You can't access heaps in one AppDomain from the other. I don't know if it's done so that GC can pause only one AppDomain; I always viewed it as more of a security and sandboxing feature.

bad_user 10y ago

If you need multiple heaps, you can already run multiple OS processes that communicate through message passing. Message passing is a little inefficient compared with shared memory concurrency, but you have to pick your poison.