RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3]
Coleen Phillimore
coleenp at openjdk.org
Mon Jun 23 20:59:29 UTC 2025
On Mon, 23 Jun 2025 11:52:46 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>> src/hotspot/share/interpreter/bytecodeTracer.cpp line 182:
>>
>>> 180: // the method has changed. If this method is redefined and removed, that's ok because the method passed in won't match, and
>>> 181: // this will print that one.
>>> 182: static Method* _current_method = nullptr;
>>
>> And if we are calling `trace_interpreter` from multiple threads they will each stomp on this shared global field. Sorry I can't see how some form of locking is not needed here.
>
> If multiple threads change the value of _current_method, the method printing will print the method name again. That's a benign race.
So actually this wasn't more racy than what was there in this respect. You could change the global method before taking the ttyLock and for multiple threads, this would claim that the current method had changed. The old code also had shared state for BytecodeTracer. Now this uses a local instance, which can then print the bytecode at the given location.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25915#discussion_r2162519648
More information about the hotspot-runtime-dev
mailing list