RFR: 8324129: C2: Remove some ttyLocker usages in preparation for JDK-8306767

[David Holmes]

On Thu, 18 Jan 2024 15:17:27 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> I'm removing some instances of `ttyLocker`. Instead of locking, I first put all the output on a `stringStream`, and then print this stream all at once, which is atomic.
> 
> Removing the `ttyLocker` is nice, because it means we have less interference with other locking mechanisms, such as the `extra_data_lock` cases I have to introduce with [JDK-8306767](https://bugs.openjdk.org/browse/JDK-8306767).
> 
> @coleenp wished that I do this separately, so I filed this RFE here.

src/hotspot/share/code/nmethod.hpp line 624:

> 622:   // print output in opt build for disassembler library
> 623:   void print_relocations()                        PRODUCT_RETURN;
> 624:   void print_pcs() { print_pcs_on(tty); }

This is a very common pattern, so I was wondering why you got rid of it?

src/hotspot/share/interpreter/bytecodeTracer.cpp line 195:

> 193:   s.set_interval(from, to);
> 194: 
> 195:   ttyLocker ttyl;  // keep the following output coherent

The previous method using ttyLocker states:

// The ttyLocker also prevents races between two threads
// trying to use the single instance of BytecodePrinter.

Is that also a concern in this method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17486#discussion_r1458328787
PR Review Comment: https://git.openjdk.org/jdk/pull/17486#discussion_r1458329948