Fwd: review(XXS): 7060842: UseNUMA crash with UseHugreTLBFS running SPECjvm2008

[Ramki Ramakrishna]

Yikes... a Linux man page i found does not say anything about swap 
reservation:

*MADV_DONTNEED*
    Do not expect access in the near future. (For the time being, the
    application is finished with the given range, so the kernel can free
    resources associated with it.) Subsequent accesses of pages in this
    range will succeed, but will result either in re-loading of the
    memory contents from the underlying mapped file (see *mmap*()) or
    zero-fill-on-demand pages for mappings without an underlying file.

Is there an understanding that this is a Linux bug? Or is "resources" 
above open to
interpretation, including swap reservation? (Andrew Haley?)

Anyway, your change looks good, if only to get back to more reliable 
operation
under tight memory situations?

PS: Igor, what does "louses" below (in yr email) mean in this context?

Reviewed!
-- ramki


On 8/3/2011 1:55 PM, Igor Veresov wrote:
> Resending to the right list.
>
> -------- Original Message --------
> Subject: review(XXS): 7060842: UseNUMA crash with UseHugreTLBFS 
> running SPECjvm2008
> Date: Wed, 03 Aug 2011 13:40:17 -0700
> From: Igor Veresov <igor.veresov at oracle.com>
> To: hotspot-compiler-dev <hotspot-compiler-dev at openjdk.java.net>
>
> It seems that madvise(MADV_FREE) breaks pages reservation semantics of
> the the underlying segment. With tight memory constraints this would
> cause a race for pages and a segfault if the JVM louses. The solution is
> to revert back to the previous implementation of os::free_memory() that
> used mmap().
>
> Webrev: http://cr.openjdk.java.net/~iveresov/7060842/webrev.00/
>
> Tested is gc test suite.
>
> igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20110803/9ed1b94a/attachment.htm>