RFR: JDK-8277056: Combining several C2 Print* flags asserts in xmlStream::pop_tag

Xin Liu xliu at openjdk.java.net
Wed Apr 20 17:38:28 UTC 2022


On Tue, 12 Apr 2022 13:15:28 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> Sometimes the writing to xmlStream is mixed from several threads, and therefore the `xmlStream` tag stack can end up in a bad state. When this occurs, the VM crashes in `xmlStream::pop_tag` with `assert(false) failed: bad tag in log`.
> 
> The logging between `xtty->head` and `xtty->tail` is guarded by a ttyLocker which also locks `VMThread::should_terminate()` (ttyLocker is needed here to serializes the output info about the termination of the VMThread). 
> 
> The problem is that `print_metadata` and `dump_asm` may block for safepoint which then releases the ttyLocker (`break_tty_lock_for_safepoint`). When the `print_metadata` or `dump_asm` continues after the safepoint other threads could have taken the ttyLocker and may be busy printing and interfere with the tag stack of `xmlStream`.
> 
> The solution is to call `print_metadata` and `dump_asm` first and let them write to a local stringStream. Then acquire the ttyLocker to do the printing (using the local stringStream) and use a separate ttyLocker for `VMThread::should_terminate()`
> 
> The same issue was already targeted in https://bugs.openjdk.java.net/browse/JDK-8153527 but the fix was incomplete.

src/hotspot/share/opto/output.cpp line 1874:

> 1872:       }
> 1873:       stringStream dump_asm_str;
> 1874:       dump_asm_on(&dump_asm_str, node_offsets, node_offset_limit);

Does dump_asm_on also require InVM like print_metadata?  If it's not, is it easier to resume ttylock right after print_metadata?

src/hotspot/share/opto/output.cpp line 1887:

> 1885:       if (C->method() != NULL) {
> 1886:         tty->print_cr("----------------------- MetaData before Compile_id = %d ------------------------", C->compile_id());
> 1887:         tty->print("%s", method_metadata_str.as_string());

is print_raw() better than  print here?  at least you don't need to handle vararg.

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

PR: https://git.openjdk.java.net/jdk/pull/8203


More information about the hotspot-compiler-dev mailing list