5 Coding Hacks to Reduce GC Overhead
takipiblog.com
5 Coding Hacks to Reduce GC Overhead
1–10 of 25 posts
Re: 5 Coding Hacks to Reduce GC Overhead
#2I was hoping for something that would be general for most GC languages, but it seems to only talk about Java.
Re: 5 Coding Hacks to Reduce GC Overhead
#3Perhaps it should be renamed to "5 Coding Hacks to Reduce GC Overhead in Java", otherwise it's not clear what it's about (in fact, even in the article, Java is not mentioned before the third paragraph).
Re: 5 Coding Hacks to Reduce GC Overhead
#4I was hoping for something that would be general for most GC languages, but it seems to only talk about Java.
I might be wrong, but it might be a bit hard to write something general enough to be useful - as most of the items can be easily translated into other languages, it would still be mostly implementation-specific / language design specific.
Re: 5 Coding Hacks to Reduce GC Overhead
#5Articles like this make me believe that Java should have just gone with a model designed around fibers that each fiber gets a fiber-local heap and objects that survive the death of the heap or are accessed in a multi-fiber way are moved to a global heap.
It would solve the problem with "stop the world" GC dynamics and increase concurrent collecting performance while also adding native fibers to the JVM (and thus make it possible to write highly concurrent software in Java much more easy).
Re: 5 Coding Hacks to Reduce GC Overhead
#6I was hoping for something that would be general for most GC languages, but it seems to only talk about Java.
The general advice is to produce less garbage. Strategies for doing so are specific to the language and APIs involved.
Re: 5 Coding Hacks to Reduce GC Overhead
#7Articles like this make me believe that Java should have just gone with a model designed around fibers that each fiber gets a fiber-local heap and objects that survive the death of the heap or are accessed in a multi-fiber way are moved to a global heap. It would solve the problem with "stop the world" GC dynamics and increase concurrent collecting performance while also adding native fibers to the JVM (and thus make…
The DLG collector as used by Caml Light does what you describe.
Updating an object in the global heap to point to a thread-local heap can cause unbounded work to be done before that update as the entire pointed-to structure has to be copied into the global heap first. GC designers really hate write barriers (sections of code that are performed before a pointer is updated) that perform unbounded work.
Re: 5 Coding Hacks to Reduce GC Overhead
#8I was hoping for something that would be general for most GC languages, but it seems to only talk about Java.
The general advice is to produce less garbage. Strategies for doing so are specific to the language and APIs involved.
It's not just that you need to produce less garbage - you want to produce less live objects in general, as a large part of the cost during GC is determining which objects are live.
Re: 5 Coding Hacks to Reduce GC Overhead
#9I'm not sure 1. is relevant anymore. Almost all JVMs default to generational GCs, which would make all those allocations basically free.
Re: 5 Coding Hacks to Reduce GC Overhead
#10+1 for Trove. Recently when working with collections with 10s of thousands of primitive elements. We saw substantial memory savings by using Trove.