Integrated: 8306922: IR verification fails because IR dump is chopped up
Emanuel Peter
epeter at openjdk.org
Mon Jun 26 06:14:16 UTC 2023
On Wed, 21 Jun 2023 14:43:18 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
> Some IR tests were failing because the logs were messed up (badly interleaved), due to multiple threads writing at the same time.
>
> The issue was in `Compile::print_ideal_ir`. While we did lock the `tty`, this lock was broken because the node dumping sometimes calls into the VM, which can trigger Safepoints, which in turn can explicitly break the locks, with `ttyLocker::break_tty_lock_for_safepoint`.
>
> What good is a lock if it can be broken? Not much. Though it is only broken if there is a Safepoint, so if we can avoid safepointing while holding the lock we should be safe. To verify that, we can write:
>
>
> NoSafepointVerifier nsv;
> ttyLocker ttyl;
>
>
> The verifier triggered immediately, as expected.
> And I now gather the whole dump into a separate `stringStream` first, so that all the Safepoints can happen before I even acquire the lock. Then, I acquire the log and just print the `stringStream` to `tty / xtty`, without triggering any Safepoint.
>
> We still need to acquire a lock, else other threads may be printing also, and we get a bad interleaving in the locks.
>
> I had to enable `dump_bfs` to print to an arbitrary stream, instead of just `tty`.
>
> I un-problemlisted `compiler/c2/irTests/TestVectorConditionalMove.java`, and fixed a CompileCommand issue for it.
>
> **Follow-up work**
>
> [JDK-8310712](https://bugs.openjdk.org/browse/JDK-8310712) C2: check for broken tty locks due to SafePoint
> We should in general go through all uses of `ttyLocker`, and add a `NoSafepointVerifier` to ensure no such lock is broken. Or maybe we just build the verifier into the ttyLocker?
>
> [JDK-8310711](https://bugs.openjdk.org/browse/JDK-8310711) IR Framework: remove safepoint while printing handling
>
> **Testing**
>
> I ran `TestVectorConditionalMove.java` 1000x on master, just with the CompileCommand issue fixed. It triggered an IR issue 5 times (hit rate `0.005`). With the fix, it never triggers (`0.995^1000 = 0.007`). I also ran up to tier6 and stress-testing.
This pull request has now been integrated.
Changeset: 9057b350
Author: Emanuel Peter <epeter at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/9057b3503349ead7d995b1a705317324830eabb2
Stats: 173 lines in 8 files changed: 26 ins; 6 del; 141 mod
8306922: IR verification fails because IR dump is chopped up
Reviewed-by: chagedorn, thartmann
-------------
PR: https://git.openjdk.org/jdk/pull/14591
More information about the hotspot-compiler-dev
mailing list