JDK-8197442 : [Graal] runtime/Metaspace/DefineClass.java crashes with "biases should not be seen by VM thread here"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10,11
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-02-08
  • Updated: 2019-06-20
  • Resolved: 2018-02-20
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 11
11Resolved
Related Reports
Duplicate :  
JDK-8197901 - Crash during GC when logging level is debug
Relates :  
JDK-8059924 - com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java: assert(Universe::verify_in_progress() || !SafepointSynchronize::is_at_safepoint()) failed: invariant
Description
runtime/Metaspace/DefineClass.java crashes with

#  Internal Error (workspace/open/src/hotspot/share/runtime/synchronizer.cpp:726), pid=23915, tid=23935
#  assert(Universe::verify_in_progress() || !SafepointSynchronize::is_at_safepoint()) failed: biases should not be seen by VM thread here

when runnning in Graal JIT mode.

Steps to reproduce:
> jtreg -vt -jdk:JDK-HS_fastdebug 
    -vmoptions:-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal 
    -dir:test/hotspot/jtreg runtime/Metaspace/DefineClass.java


The issue seems to be intermittent but I can reproduce it quite easy with latest jdk10-b43 and jdk/hs workspace.
The issue is also reproduced with previous jdk10 builds.
Comments
This is a duplicate of JDK-8197901. Klass::external_name() can be called during a safepoint. For anonymous classes, it was getting the Object.hashCode of the mirror to print the name. The mirror must be for a class that is not already verified. The linked bug has a better fix.
20-02-2018
This is similar to JDK-8059924.
09-02-2018
I can reproduce this in 1/20 runs and it seems like that most of the offending mirror klasses are Graal related. For example: {0x00000006c9d04888} - klass: 'java/lang/Class' - ---- fields (total size 14 words): - private volatile transient strict 'cachedConstructor' 'Ljava/lang/reflect/Constructor;' @12 NULL (0 0) - private volatile transient strict 'newInstanceCallerCache' 'Ljava/lang/Class;' @16 NULL (0 0) - private transient 'name' 'Ljava/lang/String;' @20 NULL (0 d9cb3977) - private transient 'module' 'Ljava/lang/Module;' @24 a 'java/lang/Module'{0x00000006ce59cbb8} (d9cb3977 d9ca3a0b) - private final 'classLoader' 'Ljava/lang/ClassLoader;' @28 a 'jdk/internal/loader/ClassLoaders$PlatformClassLoader'{0x00000006ce51d058} (d9ca3a0b 0) - private transient 'packageName' 'Ljava/lang/String;' @32 NULL (0 d93a091f) - private final strict 'componentType' 'Ljava/lang/Class;' @36 [I{0x00000006c9d048f8} (d93a091f 0) - private volatile transient strict 'reflectionData' 'Ljava/lang/ref/SoftReference;' @40 NULL (0 0) - private volatile transient 'genericInfo' 'Lsun/reflect/generics/repository/ClassRepository;' @44 NULL (0 0) - private volatile transient strict 'enumConstants' '[Ljava/lang/Object;' @48 NULL (0 0) - private volatile transient strict 'enumConstantDirectory' 'Ljava/util/Map;' @52 NULL (0 0) - private volatile transient 'annotationData' 'Ljava/lang/Class$AnnotationData;' @56 NULL (0 0) - private volatile transient 'annotationType' 'Lsun/reflect/annotation/AnnotationType;' @60 NULL (0 0) - transient 'classValueMap' 'Ljava/lang/ClassValue$ClassValueMap;' @64 NULL (0 d9ca1390) - private volatile transient 'classRedefinedCount' 'I' @96 0 - signature: Lorg/graalvm/compiler/nodes/calc/SignExtendNode$$Lambda$129; - fake entry for mirror: 'org/graalvm/compiler/nodes/calc/SignExtendNode$$Lambda$129' - fake entry for array: NULL - fake entry for oop_size: 14 - fake entry for static_oop_field_count: 0 I'm not sure why the hash code was not installed during verification (as intended by the fix for JDK-8059924) but I don't think this problem is Graal related. Moving this to hotspot/runtime for further investigation. Please assign back, if it turns out to be a compiler issue. Thanks!
09-02-2018
hs_err attached
08-02-2018