RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v2]
David Holmes
dholmes at openjdk.org
Mon Aug 25 20:26:40 UTC 2025
On Wed, 20 Aug 2025 17:31:22 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:
>
> Add missing include runtime/synchronizer.hpp
src/hotspot/share/prims/jvmtiClassFileReconstituter.cpp line 1004:
> 1002: // is_rewritten() returns false. So we won't restore the original bytecodes.
> 1003: // We hold a lock to guarantee we are not getting bytecodes
> 1004: // at the same time the linking process are rewriting them.
Suggestion:
// We acquire the init_lock monitor to serialize with class linking so we are not getting
// bytecodes at the same time the linking process is rewriting them.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26863#discussion_r2299044927
More information about the hotspot-dev
mailing list