5 ms·

It looks like a promising improvement. From the sound of it, this seems like the same sort of GC methodology that Java used the last few revs (1.5; 1.6): putti

It looks like a promising improvement. From the sound of it, this seems like the same sort of GC methodology that Java used the last few revs (1.5; 1.6): putting objects in "recent" and "old" pools. That said, I would like to see a benchmark that uses a bit more memory, not just temporary stuff to be discarded ASAP. Many of the Java promotion benchmarks do that too (focus on use of transient data only). What happens if you actually need to hold on to some state, rather than merely concatenating somebody's account info into a dynamic index.html page in a web app? Oh well, there's always memcached, I suppose. It would be nice to have languages that support app types other than stateless-as-possible web apps.

dfox 16y ago
Generational GC's are what almost every high-performance VM uses and this approach is well-tested in many practical systems. Almost all aplications tend to allocate large amounts of temporary objects, while having large amounts of memory consumed by long-living objects (I would assume that at least one half of used memory in this case are long-living objects). Also, because generational GC is almost invariably copying GC (it is possible to make non-moving generational GC, but that is more of academic interest) it tends to improve caching behavior, which is even more important with each new generation of CPUs. Main reason why copying and generational GCs are not used everywhere is that they tend to generally complicate matters when you want to seamlessly interface with C code (non-managed code in .NET terms), because objects then tend to be moved around by GC, which has to see and be able to update every reference to it's heap. In most applications and runtimes, there are a lot more behind the stages objects allocated by VM and or library routines than objects that you allocate directly in your code. Edit: and I think that Sun's JVM uses generational GC at least since 1.3, if not 1.2.
- riffraff 16y ago
  as a side note, bohem's gc is also generational http://www.hpl.hp.com/personal/Hans_Boehm/gc/#details http://www.hpl.hp.com/personal/Hans_Boehm/gc/#details
  - dfox 16y ago
    But generational collection has to be explicitly enabled by GC_enable_incremental() and whole thing looks especially experimental. Main problem is that you cannot reasonably maintain remembered set(or grey set for incremental GC) without write barriers and write barriers are not practical when you cannot modify compiler.

dfox 16y ago

Generational GC's are what almost every high-performance VM uses and this approach is well-tested in many practical systems. Almost all aplications tend to allocate large amounts of temporary objects, while having large amounts of memory consumed by long-living objects (I would assume that at least one half of used memory in this case are long-living objects). Also, because generational GC is almost invariably copying GC (it is possible to make non-moving generational GC, but that is more of academic interest) it tends to improve caching behavior, which is even more important with each new generation of CPUs. Main reason why copying and generational GCs are not used everywhere is that they tend to generally complicate matters when you want to seamlessly interface with C code (non-managed code in .NET terms), because objects then tend to be moved around by GC, which has to see and be able to update every reference to it's heap. In most applications and runtimes, there are a lot more behind the stages objects allocated by VM and or library routines than objects that you allocate directly in your code. Edit: and I think that Sun's JVM uses generational GC at least since 1.3, if not 1.2.

riffraff 16y ago
as a side note, bohem's gc is also generational http://www.hpl.hp.com/personal/Hans_Boehm/gc/#details http://www.hpl.hp.com/personal/Hans_Boehm/gc/#details
- dfox 16y ago
  But generational collection has to be explicitly enabled by GC_enable_incremental() and whole thing looks especially experimental. Main problem is that you cannot reasonably maintain remembered set(or grey set for incremental GC) without write barriers and write barriers are not practical when you cannot modify compiler.