On Tue, 26 Aug 2025 13:39:14 GMT, Evgeny Astigeevich <[email protected]> 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 > Okay I ran the test case in the issue and I see why it wouldn't be reliable. > I verified it with the new more minimalistic patch here: #26971 Thank you for the minimalistic patch. I now have a version of the jtreg test which fails more reliably. The test always passes the the previous version of #26971. BTW I have updated the title of [JDK-8277444](https://bugs.openjdk.org/browse/JDK-8277444). The issue is the data race between copy_bytecodes and class linking. So we must guarantee no data race when copy_bytecodes is used. I'll add the test to the PR soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3237447694 PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3237450933
