JDK-8038636 : speculative traps break when classes are redefined
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-03-28
  • Updated: 2019-09-13
  • Resolved: 2014-04-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 8 JDK 9 Other
8u162Fixed 9 b10Fixed emb-8u181Fixed
Related Reports
Relates :  
JDK-8040237 - nsk/jvmti/RetransformClasses/retransform001 crashed the VM on all platforms when run with with -server -Xcomp
Relates :  
JDK-8039960 - Unexpected exit from test compiler/profiling/spectrapredefineclass/Launcher.java
Description
Reported by Tom Rodriguez:

Basically MDO's need something like the clean_weak_klass_links but that's checking Method::on_stack instead.

InstanceKlass references are ok since they don't change during redefinition but new Method* are created and unused ones are freed so they need special attention.  Most MDO entries only how InstanceKlasses so they are safe.
Comments
Oh wait. It also specifies -Xmx1m. Yeah, this is never going to work with Graal now.
21-12-2018
Is there a reason why the testcase is using a ReservedCodeCacheSize of only 3M?
20-12-2018
URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a7784ddacbef User: lana Date: 2014-04-23 16:11:22 +0000
23-04-2014
URL: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a7784ddacbef User: roland Date: 2014-04-08 09:43:56 +0000
08-04-2014
ILW=Potential crash, medium (unclear), no workaround=MMH=P3
01-04-2014