Deallocating memory pages

[Hiroshi Yamauchi]

http://cr.openjdk.java.net/~hiroshi/webrevs/dhp/webrev.00/

Hi folks,

I'd like to see if it makes sense to contribute this patch.

If it's enabled, it helps reduce the JVM memory/RAM footprint by
deallocating (releasing) the underlying memory pages that correspond to the
unused or free portions of the heap (more specifically, it calls
madvise(MADV_DONTNEED) for the bodies of free chunks in the old generation
without unmapping the heap address space).

Though the worst-case memory footprint (that is, when the heap is full)
does not change, this helps the JVM bring its RAM usage closer to what it
actually is using at the moment (that is, occupied by objects) and Java
applications behave more nicely in shared environments in which multiple
servers or applications run.

In fact, this has been very useful in certain servers and desktop tools
that we have at Google and helped save a lot of RAM use. It tries to
address the issue where a Java server or app runs for a while and almost
never releases its RAM even when it is mostly idle.

Of course, a higher degree of heap fragmentation deteriorates the utility
of this because a free chunk smaller than a page cannot be deallocated, but
it has the advantage of being able to work without shrinking the heap or
the generation.

Despite the fact that this can slow down things due to the on-demand page
reallocation that happens when a deallocated page is first touched, the
performance hit seems not bad. In my measurements, I see a ~1-3% overall
overhead in an internal server test and a ~0-4% overall overhead in the
DaCapo benchmarks.

It supports the CMS collector and Linux only in the current form though
it's probably possible to extend this to other collectors and platforms in
the future.

I thought this could be useful in wider audience.

Chuck Rasbold has kindly reviewed this change.

Thanks,
Hiroshi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130118/b4ee81c3/attachment.htm>