Fwd: review(XXS): 7060842: UseNUMA crash with UseHugreTLBFS running SPECjvm2008
y.s.ramakrishna at oracle.com
Wed Aug 3 14:33:05 PDT 2011
Yikes... a Linux man page i found does not say anything about swap
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
under tight memory situations?
PS: Igor, what does "louses" below (in yr email) mean in this context?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev