Re[2]: [Gc] Workaround for problems with GetWriteWatch and fix forGC_get_heap_size/bytes_free values on unmapping

Ivan Maidanski ivmai at
Sat Aug 1 13:58:56 PDT 2009


"Boehm, Hans" <hans.boehm at> wrote:
> Thanks.
> > From:  Ivan Maidanski
> > ...
> > 2. The values returned by GC_get_heap_size() and
> > GC_get_free_bytes() if USE_MUNMAP. If the memory is unmapped
> > (returned to the OS) then the values indicating the current
> > heap size and the free memory size should be updated
> > accordingly (otherwise, the total heap size of several
> > applications running on a system may become larger than the
> > system virtual memory size, and the memory considered as
> > "free" by one application may be, in fact, in use by another one).
> This worries me a bit, though I don't immediately see anything that would break.  The problem is that both GC_large_free_bytes and GC_heapsize now mean somewhat different things depending on whether we're unmapping memory.  Up until now, unmapping memory was only an optimization that didn't much affect the rest of the collector logic.  Unmapped memory was still considered to be part of the large object free list, and part of the heap.  Since these variables are used in some performance heuristics, we now have to convince ourselves that they make sense in both scenarios.
> If the underlying problem here is the values we're reporting back to the user, does it make more sense to just keep track of the total amount of unmapped memory in a separate variable, and subtract it in GC_get_heap_size and GC_get_free_bytes, leaving the internals alone?  That strikes me as safer and easier to maintain.  Plus we have more information for debugging.
> Hans

Yes, it's about the values reported back to the user - let the sum of GC_get_heap_size() values over all processes always be no greater than system virtual memory in use at a time (or let GC_get_heap_size() == java Runtime.totalMemory() and GC_get_free_bytes() == java Runtime.freeMemory()). And, yes, this could be re-written (recall that now the getters are synch'ed) to have a separate value (unmapped memory size), and now it makes me think that the heuristics (at least some, eg. collect-or-expand tradeoff) treats GC_heapsize as mapped-heap-size plus remappable-memory-size (and the unmapped memory is a subject for further re-mapping not for allocation thru GET_MEM)...

OK, I'll rewrite that part of my patch to have a separate value (unmapped memory size).


More information about the Gc mailing list