JDK-8013938 : Native OOME on fastdebug VM on Solaris
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs24,hs25
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris
  • CPU: x86
  • Submitted: 2013-05-06
  • Updated: 2017-02-11
  • Resolved: 2013-09-04
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.
JDK 8 Other
8Fixed hs25Fixed
Related Reports
Duplicate :  
JDK-8016732 - Out of memory error in ObjectStartArray::set_covered_region
Duplicate :  
JDK-8020599 - G1: VM crashed with OOME on solaris with large heap
Relates :  
JDK-7197666 - java -d64 -version core dumps in a box with lots of memory
Relates :  
JDK-8016505 - G1: Revert back to use HeapBaseMinAddress=256m on Solaris x86
Relates :  
JDK-8020599 - G1: VM crashed with OOME on solaris with large heap
Description
There are a bunch of concurrency related tests failed during PIT of hs25-b31 for jdk8-b89

There are two OOME messages observed:
1. Due to JDK-7045180
;; Using jvm: "/bpool/local/aurora/sandbox/sca/vmsqe/jdk/pit/2013-05-03-151437.amurillo.hs25-b31-snapshot/fastdebug/solaris-amd64/jre/lib/amd64/server/libjvm.so"
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (0xe0000000), pid=6716, tid=44
#  Error: An uncaught C++ exception
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b87) (build 1.8.0-ea-fastdebug-b87)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b31-internal-201305031514.amurillo.hs25-b31-snapshot-fastdebug compiled mode solaris-amd64 compressed oops)
# Core dump written. Default location: /bpool/local/aurora/sandbox/results/ResultDir/DirectByteBufferAtomicityTests_ByteTest/core or core.6716
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

2. 
#
#  Out of Memory Error (/opt/jprt/T/P1/151437.amurillo/s/src/share/vm/memory/allocation.cpp:374), pid=7008, tid=31
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b87) (build 1.8.0-ea-fastdebug-b87)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b31-internal-201305031514.amurillo.hs25-b31-snapshot-fastdebug compiled mode solaris-amd64 compressed oops)
# Core dump written. Default location: /bpool/local/aurora/sandbox/results/ResultDir/DirectByteBufferAtomicityTests_IntTest/core or core.7008
#

The problem looks the same as in JDK-7197666
Comments
For the release notes The default starting location the Java heap on solaris-x64 platforms has been increased from 256m to 2g. This allows more space for native memory allocations (malloc'ed space) on that platform but also decreases the maximum heap available for zero based compressed references (UseCompressedOops option). Set HeapBaseMinAddress explicitly to a lower value if a larger Java heap size for zero based compressed references is desired.
06-09-2013
Will implement the suggested fix of increasing the HeapBaseMinAddress on solaris-x64 to 2G.
27-08-2013
HeapBaseMinAddress was set to 256m on solaris amd64 in order to maximize the zero based coops heap size. If the default is changed to 1g, there will be a performance regression for applications that were run with heaps between 3g and ~3.75g.
19-07-2013
Bengt's changeset only applies to G1: Changeset: f65b000853c7 Author: brutisso Date: 2013-06-14 08:02 +0200 URL: http://hg.openjdk.java.net/hsx/hsx24/hotspot/rev/f65b000853c7 8012265: VM often crashes on solaris with a lot of memory Summary: Increase HeapBaseMinAddress for G1 from 256m to 1g on Solaris x86 Reviewed-by: mgerdin, coleenp, kvn ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp I don't see any indication that this failure was using G1...
02-07-2013
This is another issue with the HeapBaseMinAddress on solaris x86. Why is it set so low again?
02-07-2013
The same behavior with test gc/metaspace/G1AddMetaspaceDependency.java in PIT on 3 May 2013. The same behavior: 100% reproducible with fastdebug build, shifting of heap start fixes the trouble. # Out of Memory Error (/opt/jprt/T/P1/151437.amurillo/s/src/share/vm/memory/allocation.inline.hpp:62), pid=23763, tid=57 # # JRE version: Java(TM) SE Runtime Environment (8.0-b87) (build 1.8.0-ea-fastdebug-b87) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b31-internal-201305031514.amurillo.hs25-b31-snapshot-fastdebug mixed mode solaris-amd64 compressed oops) # Core dump written. Default location: /bpool/local/aurora/sandbox/results/workDir/gc/metaspace/G1AddMetaspaceDependency/core or core.23763
07-05-2013
If I specify -XX:HeapBaseMinAddress=2147483648 to the VM test passes because Java heap will start from 2Gb of address space. According to https://jbs.oracle.com/bugs/browse/JDK-7197666?focusedCommentId=13306036&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13306036 VM sets HeapBaseMinAddress to 256Mb and seems that this causes the problem
06-05-2013