RFR: 8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock (running with -XX:+Verbose -XX:+WizardMode -XX:+PrintDeoptimizationDetails) [v6]

[David Holmes]

On Wed, 14 Jan 2026 13:56:46 GMT, Guanqiang Han <ghan at openjdk.org> wrote:

>> Please review this change. Thanks!
>> 
>> **Description:**
>> 
>> When -XX:+PrintDeoptimizationDetails is enabled, vframeArray.cpp prints interpreted frames under ttyLocker. 
>> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/runtime/vframeArray.cpp#L493-L503
>> In the WizardMode && Verbose branch it calls Method::print_codes() / print_codes_on(). The bytecode printing path may acquire MDOExtraData_lock (rank nosafepoint-1). 
>> https://github.com/openjdk/jdk/blob/578204f8c49f06be8b9c4855359ca61c9e107678/src/hotspot/share/interpreter/bytecodeTracer.cpp#L597-L602
>> Calling it while holding tty_lock violates the global lock ranking order and triggers a lock rank inversion assertion.
>> 
>> **Fix:**
>> 
>> Generate the bytecode dump before taking tty_lock, and print it afterwards under ttyLocker to keep the output coherent while preserving correct lock acquisition order. 
>> To avoid double buffering when the target stream is already a thread-local stringStream, extend BytecodeTracer::print_method_codes with a buffered flag . The new call site uses buffered=false when dumping into the temporary stringStream.
>> 
>> **Test:** 
>> 
>> GHA
>
> Guanqiang Han has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a compile error

src/hotspot/share/utilities/ostream.hpp line 162:

> 160:    virtual ~outputStream() {}   // close properly on deletion
> 161:    // Return true if this stream buffers/accumulates output in memory (e.g., stringStream)
> 162:    virtual bool is_buffered() const { return false; }

Really you are using this as a proxy for "do I have a stringStream?" and it doesn't quite work because we also have a `bufferedStream` class that you have not marked as buffered - though I'm not sure the "buffering" in the two cases is actually the same thing.

@dean-long you made this suggestion so how do you see `is_buffered` fitting in to the whole stream hierarchy?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/29186#discussion_r2693188249