Deallocating memory pages

[Hiroshi Yamauchi]

Vitaly, thanks for confirming that with the kernel source.


On Thu, Jan 24, 2013 at 1:47 PM, Vitaly Davidovich <vitalyd at gmail.com>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 gmail.com> 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 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/20130124/46b0a8fe/attachment.htm>