JDK-6348447 : Specifying -XX:OldSize crashes 64-bit VMs
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6,6u115
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-11-10
  • Updated: 2016-03-17
  • Resolved: 2013-02-06
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 7 JDK 8 Other
7u101Fixed 8Fixed hs25Fixed
Description
java -d64 -XX:OldSize=4200M
crashes on solaris-sparcv9, solaris-amd64, linux-amd64. 4200M is not essential, the same failure occurs with 400M. This is reproducible with fastdebug build at least since b40. I cannot reproduce this with product build b59, however I see the same failure at
http://vmsqe.sfbay.sun.com/nightly/tiger/DTWS/results/11-08-05/ServerVM/64BITSOLSPARC/mixed/Gc_Baseline/vm.gc-NIGHTLY-Gc_Baseline-ServerVM-mixed-64BITSOLSPARC-2005-11-08-20-16-18/ResultDir/MemOptions/MemOptions.tlog

The following test fails because of this bug:
	gc/64bit/quicklook/largeheap/MemOptions

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/adjoiningGenerations.cpp:27]
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/BUILD_AREA/jdk6.0-64bit/hotspot/src/share/vm/gc_implementation/parallelScavenge/adjoiningGenerations.cpp, 27 [ Unknown ]), pid=18530, tid=2
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0-beta-fastdebug-b59-debug mixed mode)
#
# Error: assert(min_low_byte_size <= init_low_byte_size && init_low_byte_size <= max_low_byte_size,"Parameter check")
# An error report file with more information is saved as hs_err_pid18530.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 2
Dumping core ...
Abort (core dumped)

Here is the stack trace
----------------- t@1 -----------------
0xffffffff7f0ca154      __lwp_wait + 0x8
0xffffffff7f0c5760      _thrp_join + 0x38
0xffffffff7f0c5900      thr_join + 0x10
0x00000001000071bc      ContinueInNewThread + 0x30
0x0000000100001b78      main + 0x3a8
0x000000010000179c      _start + 0x17c
----------------- t@2 -----------------
0xffffffff7f0ca124      _lwp_kill + 0x8
0xffffffff7f04620c      abort + 0x118
0xffffffff7d897548      void os::abort(bool) + 0x138
0xffffffff7dbb7744      void VMError::report_and_die() + 0xd14
0xffffffff7dbb85a4      void crash_handler(int,siginfo*,void*) + 0x44
0xffffffff7f0c9030      __sighndlr + 0xc
0xffffffff7f0bd7a4      call_user_handler + 0x3e0
0xffffffff7d8c293c      void ParallelScavengeHeap::print_on(outputStream*)const + 0x34
0xffffffff7dbb67e0      void VMError::report(outputStream*) + 0xc10
0xffffffff7dbb71d4      void VMError::report_and_die() + 0x7a4
0xffffffff7dbb85a4      void crash_handler(int,siginfo*,void*) + 0x44
0xffffffff7f0c9030      __sighndlr + 0xc
0xffffffff7f0bd7a4      call_user_handler + 0x3e0
0xffffffff7d119520      void frame::print_on_error(outputStream*,char*,int,bool)const + 0x30
0xffffffff7dbb6330      void VMError::report(outputStream*) + 0x760
0xffffffff7dbb71d4      void VMError::report_and_die() + 0x7a4
0xffffffff7d085b6c      void report_assertion_failure(const char*,int,const char*) + 0x6c
0xffffffff7cdd0f60      AdjoiningGenerations::AdjoiningGenerations #Nvariant 1(ReservedSpace,unsigned long,unsigned long,unsigned long,unsigned long,unsigne
d long,unsigned long,unsigned long) + 0x90
0xffffffff7d8bf99c      int ParallelScavengeHeap::initialize() + 0x62c
0xffffffff7db1ad34      int universe_init() + 0x49c
0xffffffff7d1b50b8      int init_globals() + 0x58
0xffffffff7dad8d88      int Threads::create_vm(JavaVMInitArgs*,bool*) + 0x2e8
0xffffffff7d362130      JNI_CreateJavaVM + 0x110
0x000000010000391c      InitializeJVM + 0x134
0x0000000100001c64      JavaMain + 0xbc
0xffffffff7f0c8f04      _lwp_start
Comments
Is it applicable for 6ux ? AffectedVersion says '6'.
15-03-2016
Unfortunatelly we don't have nightly results because of the JDK-8151889. Nightly builds will be ready by tomorrow. But taking into account this is a fix of regression introduced in the current CPU we are OK to take the risk and take this into CPU16_02
15-03-2016
Marking this as a regression. Note that it wasn't a regression in JDK 8, but it was introduced as a regression in JDK 7
15-03-2016
Critical Request Template - Justification : The backport of JDK-7112912 exposed this issue in JDK 7, causing the regression seen in JDK-8149739 - Risk Analysis : Very small fix. Fix has been in JDK 8 since 2013 - Webrev : http://closedjdk.us.oracle.com/jdk7u/jdk7u-cpu/hotspot/rev/f7c34a047f0d - Testing (done/to-be-done) : Run failing test in JDK-8149739 to verify that it passes - Back ports (done/to-be-done) : Done - Fix For Release : JDK 7
15-03-2016
This issue was exposed in JDK 7 by the backport of JDK-7112912. JPRT job for this fix is running, should be pushed later today
14-03-2016