<div dir="ltr">Vitaly, thanks for confirming that with the kernel source.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 24, 2013 at 1:47 PM, Vitaly Davidovich <span dir="ltr"><<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Hiroshi,</p>
<p dir="ltr">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.</p>
<div class="im HOEnZb">
<p dir="ltr">Thanks</p>
<p dir="ltr">Sent from my phone</p>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_quote">On Jan 18, 2013 9:20 PM, "Vitaly Davidovich" <<a href="mailto:vitalyd@gmail.com" target="_blank">vitalyd@gmail.com</a>> wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">Hi Hiroshi,</p>
<p dir="ltr">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.</p>
<p dir="ltr">Thanks<br></p>
<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On Jan 18, 2013 6:30 PM, "Hiroshi Yamauchi" <<a href="mailto:yamauchi@google.com" target="_blank">yamauchi@google.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_default"><a href="http://cr.openjdk.java.net/~hiroshi/webrevs/dhp/webrev.00/" target="_blank">http://cr.openjdk.java.net/~hiroshi/webrevs/dhp/webrev.00/</a><br></div><div class="gmail_default">
<br></div><div class="gmail_default">Hi folks,</div><div class="gmail_default"><br></div><div class="gmail_default">I'd like to see if it makes sense to contribute this patch.</div><div class="gmail_default">
<br></div><div class="gmail_default">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).</div>
<div class="gmail_default"><br></div><div class="gmail_default">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. </div>
<div class="gmail_default"><br></div><div class="gmail_default">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.</div>
<div class="gmail_default"><br></div><div class="gmail_default">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.</div>
<div class="gmail_default"><br></div><div class="gmail_default">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.</div>
<div class="gmail_default"><br></div><div class="gmail_default">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.</div>
<div class="gmail_default"><br></div><div class="gmail_default">I thought this could be useful in wider audience.</div><div class="gmail_default"><br></div><div class="gmail_default">Chuck Rasbold has kindly reviewed this change.</div>
<div class="gmail_default"><br></div><div class="gmail_default">Thanks,</div><div class="gmail_default">Hiroshi</div><div class="gmail_default"><br></div></div>
</blockquote></div>
</blockquote></div>
</div></div></blockquote></div><br></div>