Deallocating memory pages

[Jon Masamitsu]

Hiroshi,

This is a nice feature but I'm asking myself what type
of applications would see significant footprint reductions.
Would they be

1) applications whose heap usage varies significantly
over time so that there are periods when some large
fraction of the heap is unused and

2) applications with many objects larger than a page so that freeing
those objects could free memory.

Is that a good guess or is it more general than that?

Jon

On 1/18/2013 3:29 PM, Hiroshi Yamauchi 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
>