Skip to content

Concurrent ClassLoader#defineClass prone to data race #22129

@beikov

Description

@beikov

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions