JDK-6920293 : OptimizeStringConcat causing core dumps
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs17,6u18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc,itanium
  • Submitted: 2010-01-26
  • Updated: 2010-04-02
  • Resolved: 2010-03-02
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
6u21Fixed 7Fixed hs17Fixed
Related Reports
Duplicate :  
JDK-6923675 - JVM dumps core in C2 compiled code when -XX:+OptimizeStringConcat is used
Relates :  
JDK-6914436 - 6.0_18-b04 server compiler issue
Description
When I run tests with HS17 builds and -XX:+OptimizeStringConcat, the JVM will eventually core dump:

Error: guarantee(cont_offset != 0,"unhandled implicit exception in compiled code")

This happens only when -XX:+OptimizeStringConcat is enabled, so it seems different than 6914436, though of course they may have the same root cause. I have been using OptimizeStringConcat on HS17 in the latest JDK7 build but also in JDK6 builds my moving the libjvm.so

I have attached the fastdebug output and hs_err file; core file is at ftp://javaperf.sfbay/pub/cores/core.stringconcat.gz. And yes, it's one of those bugs I can only reproduce on our big spec tests, though it reproduces quite easily so I can get more info quickly.
Comments
EVALUATION The code for the idiom a == null ? "null" : a) in OptimizeStringConcat was putting an explicit NOTNULL on the result Phi which allowed the optimizer to move some loads above the null check which caused a crash. The fix is to use the same idiom the parser uses which is to cast the resulting value to be notnull and leave the phi type alone. Tested with failing test from report. I also made some changes to error reporting to make the crash output more useful. Currently if we don't find an implicit exception handler we die inside the VM and don't print out much useful information. Instead we should simply return null and let the VMError machinery produce a normal crash dump. I also fixed the formatting for the register in 64 bit mode on solaris to match the linux formatting.
05-02-2010
EVALUATION ChangeSet=http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/3f5b7efb9642,ChangeRequest=6920293
05-02-2010