Deallocating memory pages

[Vitaly Davidovich]

Hi Hiroshi,

I'm not an official reviewer, but I wonder whether deallocate_pages_raw in
os_linux.cpp should handle an EAGAIN return value from madvise.
Specifically, should the code loop on EAGAIN and retry the syscall? Maybe
have some safety value there to stop looping if too many tries (or too much
time) are failing.

Thanks

Sent from my phone
On Jan 18, 2013 6:30 PM, "Hiroshi Yamauchi" <yamauchi at google.com> wrote:

> 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/e77fcf62/attachment.htm>