RFR: 8295851: Do not use ttyLock in BytecodeTracer::trace [v3]

[Coleen Phillimore]

On Tue, 24 Jun 2025 02:50:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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.
>
> So the old code (mis)used a shared `ByteCodeTracer` instance, and the new code gives each use a local `ByteCodeTracer` but seeds it from the global shared field. So I agree the level of raciness seems unchanged.
> 
> But printing an unrelated method name still seems a bad thing to do. ??
> 
> BTW it is also very confusing to give the global variable the same name as the private field in `ByteCodeTracer`.

It would print the right name it would just print it again.  Say:
t1 printing M1 so prints the name
t1   aload
t1    astore
t2 printing M2 method name
t2  getfield
t1 < continues printing M1 but method name was changed to M2> prints M1 method name
t1 invokevirtual
...

The thread id is printed before each line.  Using this with multiple threads is not ideal for getting information clearly but that's not what people do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25915#discussion_r2163825644