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