JDK-6700107 : java/lang/Class/forName/TooManyDimensions.java crashes with SIGSEGV in c2 compiler with fastdebug
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs12,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_10
  • CPU: generic,x86
  • Submitted: 2008-05-10
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
Related Reports
Duplicate :  
JDK-6680418 - jck60010 fails from stack overflow in VM due to deep recursion.
Description
java/lang/Class/forName/TooManyDimensions.java crash with SIGSEGV

Problem Description    : java/lang/Class/forName/TooManyDimensions.java crashes with SIGSEGV 
                         with 64bit jvm on solaris-amd64 platforms in c2 compiler

Java Release            : hs12
Java Builds             : b03
VM flavors              : server
VM Modes                : -Xmixed |-Xcomp
Java flags              :
Platform(s)             : solaris-amd64
Comments
EVALUATION 6700107: java/lang/Class/forName/TooManyDimensions.java crashes with SIGSEGV in c2 compiler with fastdebug Summary: objArrayKlass::compute_modifier_flags was unnecessarily recursive Reviewed-by: kamg
14-10-2008
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/443791f333a2
14-10-2008
EVALUATION We could rewrite the recursive array klass allocation, that would be a good improvement and would probably help performance for large multidimensional array allocation. It has locking for multithreading, so is not a trivial change. This bug from this report was cause by a stack overflow because during the recursive array class allocation, we call compute_modifier_flags at each level of the recursive allocation, which recurses for each level to get to the bottom element type. The bottom_klass() is available at each level making this recursion unnecessary and increases the risk of stack overflow error, as well as having poor performance. Fixing this allows this test to run. As far as I can tell, nothing in the compressed oops code fixed this other than possibly changing the amount of stack used somewhere.
07-10-2008