Deallocating memory pages

Vitaly Davidovich vitalyd at
Thu Jan 24 21:47:22 UTC 2013

Hi Hiroshi,

I don't have any experience with this and a quick Google didn't turn
anything up.  Browsing Linux kernel source (mm/madvise.c madvise_dontneed)
doesn't show anything that would return it (just EINVAL in some cases).  I
was only going by the man page for madvise, but it's a bit general.  I
guess I'd ignore this and leave your code as-is since I doubt the behavior
will change on Linux.  Sorry for the noise.


Sent from my phone
On Jan 18, 2013 9:20 PM, "Vitaly Davidovich" <vitalyd at> wrote:

> 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> wrote:
>> 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: <>

More information about the hotspot-gc-dev mailing list