RFR: 8277444: Data race between JvmtiClassFileReconstituter::copy_bytecodes and class linking [v3]

Evgeny Astigeevich eastigeevich at openjdk.org
Fri Sep 5 19:33:12 UTC 2025


On Wed, 27 Aug 2025 06:37:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> (I realize this is a tangent, but maybe there is a separate bug here...)
>> 
>>> To have a Class object it must have already undergone the "preparation" part of linking (it is done at the end of loading when we create the class mirror).
>> 
>> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced:
>> 
>> https://github.com/openjdk/jdk/blob/c75534517729b903b63263cf64dc2ff841e3dcb1/src/hotspot/share/oops/instanceKlass.cpp#L1064
>> 
>> Class.forName(name, false, loader) would result in a prepared class but without the event being sent.
>
>> If that's what "preparation" means, and Class.forName(name, false, loader) does not link the class, then posting the event here in InstanceKlass::link_class_impl() instead of earlier seems misplaced
> 
> @dean-long it seems the JVM TI "prepare" event is somewhat misnamed. It states "At this point, class fields, methods, and implemented interfaces are available, and no code from the class has been executed." but that neither describes preparation, nor the rest of linking. You can only access fields and methods after a class has been initialized! But lets take this elsewhere if needed.

@dholmes-ora, Thank you for review.

> I'm not sure about the test, in particular the attempt to calculate MIN_LINK_TIME_MS. It is very hard to see/know that you will actually induce the desired race. 

Making a reliable regression test was a problem.
`MIN_LINK_TIME_MS` is based on the reproducer from JDK-8277444 and my experiments on x86 and arm64 hosts.
Maybe the time is not the best. As you wrote there is no way to know the race has happened.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3259506293


More information about the serviceability-dev mailing list