JDK-4985189 : Initial 256m heap size causing crash using 1.4.2_01
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_01
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2004-01-29
  • Updated: 2004-09-10
  • Resolved: 2004-09-10
Related Reports
Relates :  
JDK-4985197 - 1.4.2_03-b02 Crashes during Concurrent collections
Description
Customer has a server application that has a max heap of -Xmx1024m using 
both the parallel and concurrent collectors. When the program heap is sized at
-Xms256m or less, their app crashes.

The stack trace from a core using a 1.4.2 fastdebug shows:

 ff2b595c abort    (ff33c000, a277f188, 0, fffffff8, 4,
a277f1a9) + 100
 fdc8f55c __1cCosFabort6Fi_v_ (1, fe0cd6bc, a277fa08,
7efefeff, 81010100, ff00) + 9c
 fd7e4e70 __1cMreport_error6Fipkci11E_v_ (fe71ba90, fe764aa4,
29c00, 29d98, 46, a) + 800
 fd7e4254 __1cYreport_assertion_failure6Fpkc1i1_v_ (fe43b192,
fe43b1dc, 217, fe43b223, fe6a2324, 0) + 54
 fdbf0d98 __1cILoadNodeFValue6kMpnOPhaseTransform__pknEType__
(3120e34, a2780f94, fe43a376, deadbc00, 1b2668, fe723df0) +
3e8
 fdd0fcf4 __1cIPhaseGVNJtransform6MpnENode__2_ (a2780f94,
3120e34, 3120cc4, 1b2668, c, 11) + 140
 fdb74aa4
__1cOLibraryCallKitUinline_unsafe_access6MiiinJBasicType__i_
(19ca2a0, a27811e8, 0, 0, fe72429c, fe6fe5b4) + 1f00
 fdb6c988 __1cOLibraryCallKitNtry_to_inline6M_i_ (a277fda4,
1f6b800, fe6a2324, fe123974, 29c00, 29f24) + 320
 fdb6c42c __1cQLibraryIntrinsicIgenerate6MpnIJVMState__2_
(321c4a4, 1f6b800, 29f20, fe0e79f6, fd8239d8, 3e1d5232) + 23c
 fd823b44 __1cFParseHdo_call6M_v_ (fe0e73bb, 1f6b800, 321c4a4,
1f6b800, 0, 31209f5) + 5ec

Using -XX:CompileCommand=exclude,com.sun.tools.javac.v8.code.ClassReader.list
to exclude the ClassReader.list method from being compiled didn't work and 
the crash also occurred using the client VM. 

They are running with the following GC parameters :

-Xms256m
-Xmx1024m
-XX:NewSize=100m
-XX:MaxNewSize=100m
-XX:+PrintCompilation
-XX:CMSInitiatingOccupancyFraction=20
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:+UseParNewGC
-XX:MaxTenuringThreshold=0
-XX:MaxPermSize=256MB
-XX:PermSize=3m
-XX:MinPermHeapExpansion=1m
-XX:MaxPermHeapExpansion=10m
-XX:-UseAdaptiveSizePolicy
-XX:+DisableExplicitGC
-XX:FreqInlineSize=650
-XX:MaxInlineSize=70
-XX:+PrintTenuringDistribution
-XX:+PrintHeapAtGC
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-Xnoclassgc

Attached are the following files:
hs_err_pid17355.log
pid17355.args.txt       the arguments passed to the program
pid17355.env.txt        the environment in which the program ran
pid17355.pldd.txt
pid17355.pmap.txt
pid17355_core_info.txt  Information extracted from the core, including
memory and cpu usage
Comments
EVALUATION The assertion failure using 1.4.2 fastdebug is probably not relevant to the original failure and was fixed in 1.5.0 as bugfix 4906992. This assert could be ignored via -XX:SuppressErrorAt='memnode.cpp:535' fd7e4254 __1cYreport_assertion_failure6Fpkc1i1_v_ (fe43b192, fe43b1dc, 217, fe43b223, fe6a2324, 0) + 54 ^^^ hexadecimal line number (decimal value 535) If the original problem occurred with both -server and -client then it's not likely a compiler problem. The hotspot.log file from a run with -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation would be helpful. ###@###.### 2004-01-29 If the original problem occurred with both -server and -client then it's unlikely to be a compiler issue. A run with the following options may help determine if it's a GC issue: -XX:+PrintGC -XX:+PrintGCDetails -XX:+VerifyBeforeGC -XX:+VerifyAfterGC Requires a nonproduct build jvm (such as a fastdebug or optimize build, but the fastdebug may assert in the server compiler so it will also need the -XX:SuppressErrorAt='memnode.cpp:535' option. ###@###.### 2004-02-02 Asked for a rerun with a fastdebug version and an assert suppression: -XX:SuppressErrorAt='/memnode.cpp:535' but have not heard back from customer/Sun-rep. Closing as "not reproducible." ###@###.### 2004-09-10
10-09-2004