Deallocating memory pages

[Hiroshi Yamauchi]

> 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.
>

Exactly.


>
> 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.
>

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130128/49e345b3/attachment.htm>