JDK-8022662 : Reduce calls to vm_exit_out_of_memory() for commit_memory() failures.
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux,solaris
  • Submitted: 2013-08-08
  • Updated: 2019-02-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Duplicate :  
JDK-8152193 - GC heap memory usage does not take into consideration overcommit_memory setting
Relates :  
JDK-8022772 - HeapWord*PSOldGen::expand_and_allocate fails
Relates :  
JDK-6843484 - os::commit_memory() failures are not handled properly on linux
Description
Currently if we fail to commit memory on linux or solaris we
do a VM exit.  This failure has shown up in the nightly testing
in the last few builds.  Because of the loss of the reservation
on the memory, this is a reasonable action to take.  For background
see

https://jbs.oracle.com/bugs/browse/JDK-6843484

The original problem was

1) GC reserved memory
2) GC tries to commit memory and fails and looses
the reservation on the memory.
3) Other thread gets reserves the memory.
4) GC again tries to commit because it thinks
it still has the memory.

Dan considered reserving the memory again after 2)
but there would be a race with 3) so instead calls
a VM exit.

Should we consider after 2) reducing the size of
the VirtualSpace so that GC does not try to do
4)?
Comments
Shrinking the address range covered by the VirtualSpace would be a logical way to prevent additional attempts but a simpler solution might be to prohibit any further expansions of the VirtualSpace by noticing when a commit has failed and setting a flag. My concern is that the owner of the VirtualSpace may have extracted some information about the address range and stored it away somewhere with the assumption that it will never change. If we can preclude that possibility, reducing the address range seems the better solution.
10-09-2013
1) I have always thought of a VirtualSpace as having one contiguous block of addresses. Rather than have a VirtualSpace have multiple segments of address space, I think it would be simpler to have multiple VirtualSpaces. 2) I'm considering this as a simpler way of avoiding the vm exit. Not necessarily the complete solution but when all else fails, a response that is preferable to a vm exit.
10-09-2013
Interesting idea. A couple of questions: 1) Does a VirtualSpace assume/require adjacent pages when it grows? The reason I ask is that after step #3 above, another thread will "own" page(s) of memory in the "middle" of what used to be the original VIrtualSpace. 2) Is this idea being pursued instead of the mprotect() solution that is being discussed in JDK-8007074? The reason that I ask is that my experiments with mprotect() instead of mmap() (remap) have revealed that, while we don't lose the original reservation mapping (yea!), the mprotect() call does not actually reserve the backing store for the "committed" memory. This means that the process will get a SIGSEGV when backing store can't actually be allocated instead of a nice error from the mprotect() call.
12-08-2013