On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <eastigeev...@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 (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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3225699087
