Deallocating memory pages

Hiroshi Yamauchi yamauchi at
Mon Jan 28 23:15:18 UTC 2013

> So when a coalesced page gets added back to the free lists it can
> deallocate
> memory even if the neither of the objects coalesced was greater than a
> page in size.  Cool.


> Do you see any increase in the sweeping times?  Or the young gen
> collection times?

In an internal server test, the total GC pause time (which is mostly the
young gen collection times) had a ~3% overhead (while the total execution
time had a ~1-2% overhead.) The concurrent sweep time had a ~10% overhead
while the whole concurrent collection time (from the beginning of the
ininitial mark phase to the end of the reset phase) had a ~3-4% overhead.
So, yes. The numbers are not completely noise-free, but these are most
likely due to the cost of calling madvise and page reallocation.

> You mention that you don't deallocate the headers of objects on the free
> list.
> Was that because you tried deallocation that included the headers and that
> was worse?

No, I don't deallocate the header of a free chunk because it contains valid
data (the prev, the next pointers, and the size) as it becomes a node in a
(doubly-linked) free list.

> I'll get feedback from the other GC guys and let you know what we
> want to do.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-gc-dev mailing list