RFR: 8370044: TraceBytecodes shouldn't break up lines

[Johan Sjölen]

On Fri, 20 Feb 2026 11:12:48 GMT, Paul Hübner <phubner at openjdk.org> wrote:

> Hi all, 
> 
> This patch addresses bytecodes being torn/mangled when printing concurrently (i.e., tracing the bytecodes of concurrently executing threads). Taking `invokeinterface` on `foo` as an example, the output could look something like the following two, ranging from mangled but legible to completely illegible:
> 
> jint[27651] [27395]   696080    64  invokeinterface,  116 <CoherentBytecodeTraceTest$Strategy.foo(I)V> 
> 
> 
> [43267]   696692    64  invokeinterface
> )
> [33283] [27395] [27907]   696694    29  fast_agetfield 116 <CoherentBytecodeTraceTest$Strategy.foo(I)V> 
> 
> 
> The solution is to buffer each bytecode print into a `stringStream` before giving it to the tty. This avoids having to take a tty lock. With this solution, the print looks as follows (note: different occurrence so surrounding bytecodes differ):
> 
> [25347]   685730    61  iconst_1
> [25091]   685717    64  invokeinterface 190 <CoherentBytecodeTraceTest$Strategy.foo(I)V> 
> [24579]   685732    20  invokestatic 125 <java/util/concurrent/ConcurrentHashMap.spread(I)I> 
> [24579]   685734    23  istore #4
> 
> 
> I introduce a test case that finds `<CoherentBytecodeTraceTest$Strategy.foo(I)V>` and ensures the bytecode preceding it is correct. This reliably failed every time previously, and does not fail after my change.
> 
> Parsing the code, I noticed that bytecode printing takes a parameter `bool buffer = true` which internally buffer to a `stringStream` before flushing to the provided `outputStream`. There were numerous places where the calling code was performing buffering itself without passing `buffer = false`, effectively double buffering. This has been addressed.
> 
> Testing: tiers 1-4. on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

Seems fine, but a few comments.

I don't know if `DEBUG` variable is necessary, maybe always print the debug lines? It's not a lot of output.

test/hotspot/jtreg/runtime/interpreter/CoherentBytecodeTraceTest.java line 80:

> 78:             thread.join();
> 79:         }
> 80:     }

Don't need the comments, imho.

test/hotspot/jtreg/runtime/interpreter/CoherentBytecodeTraceTest.java line 96:

> 94:         // back from the interface name to ensure that the thing that
> 95:         // preceeds it is an invokeinterface with a constant pool reference.
> 96:         Pattern reverseFirstPart = Pattern.compile(" \\d+ ecafretniekovni");

Write out the string in correct order and reverse it with a method call

test/hotspot/jtreg/runtime/interpreter/CoherentBytecodeTraceTest.java line 98:

> 96:         Pattern reverseFirstPart = Pattern.compile(" \\d+ ecafretniekovni");
> 97:         for (String line : lines) {
> 98:             int cbttsFoo = line.indexOf(THE_METHOD);

Ah yes, the well-known concept of `cbtts`, I totally get what that means ;-).

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29842#pullrequestreview-3831570915
PR Review Comment: https://git.openjdk.org/jdk/pull/29842#discussion_r2832756841
PR Review Comment: https://git.openjdk.org/jdk/pull/29842#discussion_r2832765442
PR Review Comment: https://git.openjdk.org/jdk/pull/29842#discussion_r2832770145