Deallocating memory pages

[Hiroshi Yamauchi]

Hi Vitaly,

Thanks for the feedback.

It's a good point. I looked into this and a Linux kernel engineer that I
know tells me that madvise(MADV_DONTNEED) won't return with error
code EAGAIN in the Linux implementation though I don't think it's what the
spec necessarily guarantees. I personally haven't seen it fail that way in
my experience. That said, it'd be no problem to change it so it does retry
several times in a loop for the extra defensiveness. Vitaly (or anyone
else), do you have experience with this?

Hiroshi

On Fri, Jan 18, 2013 at 6: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/51da0f11/attachment.htm>