RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3]

[Coleen Phillimore]

On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> There is a race between `JvmtiClassFileReconstituter::copy_bytecodes` and `InstanceKlass::link_class_impl`.  `InstanceKlass::link_class_impl` can be rewriting bytecodes. `JvmtiClassFileReconstituter::copy_bytecodes` will not restore them to the original ones because the flag `rewritten` is `false`. This will result in invalid bytecode.
>> 
>> This PR adds a lock (`init_lock`) to the `copy_bytecodes` method to prevent reading bytecodes while they are being rewritten during class linking.
>> 
>> Tested fastdebug and release builds: Linux x86_64 and arm64
>> - The reproducer from JDK-8277444 passed.
>> - Tier1 - tier3 passed.
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Symplify comments; Get JavaThread::current in variable

The problem might be higher in the call stack than here.  I think JvmtiEnv::GetBytecodes should link the class first, rather than have this race.  The bytecode rewriter already restores the bytecodes to their pre-rewritten state when it returns them.  Also, it seems that you would want to only return bytecodes that have been verified, which is also part of linking.

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

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26863#pullrequestreview-3159740645