RFR: 8277444: Race condition on Instrumentation.retransformClasses() and class linking [v3]
Evgeny Astigeevich
eastigeevich at openjdk.org
Wed Aug 27 13:21:50 UTC 2025
On Wed, 27 Aug 2025 13:12:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> 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.
Hi @coleenp,
> 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.
Should we have a separate JBS issue to cover `JvmtiEnv::GetBytecodes`?
[JDK-8277444](https://bugs.openjdk.org/browse/JDK-8277444) covers the issue with `JvmtiEnv::RetransformClasses`.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26863#issuecomment-3228175667
More information about the hotspot-dev
mailing list