-
Notifications
You must be signed in to change notification settings - Fork 764
Description
Testing with JDK 21.0.7+6 on Windows and Linux x86_64 have shown that ClassLoader#defineClass
and/or Lookup#defineClass
are prone to data races on OpenJ9.
When two or more threads concurrently attempt to define a class on a class loader through either calling ClassLoader#defineClass
or indirectly through Lookup#defineClass
, then quite often (or always?), both calls return successfully. With Hotspot, it is guaranteed that only one thread can return successfully and all the other threads will fail with a LinkageError
. The Hotspot JVM even has a flag to control this behavior, because the JVMS is apparently not clear on this according to the description of the flag. See AllowParallelDefineClass
.
Attached you can find a reproducer for this bug: openj9-bug.zip
Can you please clarify/confirm that this is a JVM bug? Due to a mistake on our side, we were trying to define a class X with different bytecode in two different threads. The different bytecode is due to a bytecode generation library producing random field names for certain features, which is roughly reflected by the attached reproducer.
I would be curious about the expectations that users can have from the defineClass
API, since I guess that this might affect how bytecode libraries like Bytebuddy want to make use of the API.
Also see raphw/byte-buddy#1827 and https://issues.redhat.com/browse/WFLY-20641 for reference.