JDK-6237349 : hotspot crashes when c1 compiler thread is running in 6.0b26
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,windows_xp
  • CPU: x86
  • Submitted: 2005-03-08
  • Updated: 2010-08-03
  • Resolved: 2005-03-30
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 JDK 6
1.4.2_10Fixed 6 b30Fixed
Related Reports
Duplicate :  
JDK-6216426 - JCK1.5a: api/java/awt/interactive/DnDComponentTest crashs, linux
Description
C1 compiler crashes easily with the attached simple java program.

1) Compile 2 java files.
2) Launch  "java  LogEngine"

The following message shows up and VM crashes.
----->
K:\c1-crash-20050308\en>java -showversion LogEngine
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b26)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b26, mixed mode)

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d6d0c64, pid=1692, tid=3808
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-ea-b26 mixed mode)
# Problematic frame:
# V  [jvm.dll+0x10c64]
#
# An error report file with more information is saved as hs_err_pid1692.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

<----

CONFIGURATION :
   JRE/JDK : 6.0b26, 5.0 1.4.2_07
   OS      : WinXP(SP1, Japanese)
   CPU     : Pentium IV 1.4[GHz]
   MEM     : 386 MB

###@###.### 2005-03-08 08:27:38 GMT
Comments
SUGGESTED FIX Webrev of fix: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20050323192658.kbr.c2_baseline/workspace/webrevs/webrev-2005.03.23/index.html ###@###.### 2005-03-24 22:03:06 GMT
24-03-2005
EVALUATION The root cause of this failure is poor handling of high register pressure by the current C1 backend. C1's UnsafePutRaw instruction, which implements stores into New I/O direct buffers, requires several inputs: the Unsafe object, the destination address, the index (if present), and the value. The current code generation sequence loads these values into registers in this order. Stores into byte buffers on x86 require a register for the value which can be treated as a byte, namely EAX through EDX; in this particular test case, because the value was being loaded last, and because of the register allocator's preference in assigning registers, the compiler ran out of byte registers and could not spill any, leading to an assertion failure. All x86 C1 releases from 1.4.x through 1.6 have this problem. The simplest solution is to force the value to be loaded earlier so it has the best chance of getting a byte register. ###@###.### 2005-03-24 22:02:00 GMT
24-03-2005