[gclist] Sharing GC resources between applications

James Hague jamesh at Volition-inc.com
Fri Mar 18 07:27:10 PST 2005


> 1. Is this a valid concern?
> 
> 2. Is there any research activity going on to address this concern?
> 
> 3. What could be a potential solution for this problem? For example:
> Would it be possible to share a single garbage collected heap between
> processes? Or could garbage collectors in separate processes be made to
> communicate so that one would free up some memory for use by the other?

I don't about .net and Java, but I have a lot of experience with Erlang.
Erlang is a garbage collected, concurrency-oriented language.  That means
that you can have thousands (or even tens of thousands) of processes all
running at once.  Erlang is used for soft-realtime telecom applications, but
has also been used for a variety of other things, like the Wings3D modeler
for Windows/Linux/OS X.

In the current implementation, Erlang has a separate heap per process.
These heaps are dynamically resized as necessary, but there's no doubt that
things would be more memory efficient if there were one giant heap, rather
than a lot of little heaps each with extra space tacked onto it.  This has
been the subject of research in the Erlang community, and an experimental
"single heap" system is available.

The reason the single heap version is not the default, is that it greatly
increases the average garbage collection time.  If you have 1000 processes,
and each has a 32K heap, then odds are that only relative few of those
processes will ever need to be GCed at the same time.  If you roll them all
together into a 32,000K heap, then the GC for that heap is potentially going
to be very expensive.  Both the separate-heap and shared-heap have the same
worst case behavior, but the average behavior is much better for separate
heaps.

I don't know if this helps or not!

James


More information about the GClist mailing list