Deallocating memory pages

Hiroshi Yamauchi yamauchi at
Thu Jan 24 22:24:40 UTC 2013

Vitaly, thanks for confirming that with the kernel source.

On Thu, Jan 24, 2013 at 1:47 PM, Vitaly Davidovich <vitalyd at>wrote:

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