for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity

John Rose john.r.rose at
Sun Feb 9 06:15:51 UTC 2020

On Jan 20, 2020, at 6:29 AM, Tobias Hartmann <tobias.hartmann at> wrote:
> While trying to reproduce this issue, I've hit some issues:
> 1) #  assert(strchr(class_name, '.') == 0LL) failed: external form of class name
> Stack: [0x000000b1eca00000,0x000000b1ecb00000]
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [jvm.dll+0xb09e61]  os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:369)
> V  [jvm.dll+0xd36c6b]  VMError::report+0xf0b  (vmerror.cpp:725)
> V  [jvm.dll+0xd3851e]  VMError::report_and_die+0x8ae (vmerror.cpp:1533)
> V  [jvm.dll+0xd38c14]  VMError::report_and_die+0x64 (vmerror.cpp:1317)
> V  [jvm.dll+0x4e5202]  report_vm_error+0x102  (debug.cpp:264)
> V  [jvm.dll+0xc08482]  StringUtils::class_list_matches+0x72 (stringutils.cpp:97)
> V  [jvm.dll+0x45f4f0]  ClassFileParser::parse_stream+0x660 (classfileparser.cpp:6450)
> V  [jvm.dll+0x44e567]  ClassFileParser::ClassFileParser+0x507 (classfileparser.cpp:6264)
> V  [jvm.dll+0x921db3]  KlassFactory::create_from_stream+0x1d3 (klassfactory.cpp:204)
> V  [jvm.dll+0xc7aa1b]  SystemDictionary::resolve_from_stream+0x21b (systemdictionary.cpp:1163)
> V  [jvm.dll+0x7bb3c2]  jvm_define_class_common+0x252  (jvm.cpp:975)
> V  [jvm.dll+0x7c542c]  JVM_DefineClassWithSource+0x20c (jvm.cpp:999)
> C  [java.dll+0x1970]  Java_java_lang_ClassLoader_defineClass1+0x140 (classloader.c:133)
> Seems to happen only on Windows.

This is pretty foul, since classFileParser.cpp assumes that _class_name
is in internal form, not external form.  There are lots of places where
it is compared with known class names using ‘/‘ instead of ‘.’ in the
package prefix.  Probably a bug in the caller, but I don’t want to chase
it now.  I’ll do something to make the CFP more robust, but we should
probably chase it down.  I’ll log a bug.

— John

More information about the valhalla-dev mailing list