for review: 8236522: "always atomic" modifier for inline classes to enforce atomicity
John Rose
john.r.rose at oracle.com
Sun Feb 9 06:15:51 UTC 2020
On Jan 20, 2020, at 6:29 AM, Tobias Hartmann <tobias.hartmann at oracle.com> 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