RFR (XS): 8208480: Fix for test failure: assert(is_bound() || is_unused()) after JDK-8206075 in C1

[Schmidt, Lutz]

Hi,

I’m responding on Gunter’s behalf. He just left the office a few minutes ago.

The bailout case was a “codecache full” condition. For the error to occur, you must run into that condition when a reference to the label is already generated, but the label is not bound yet. This is not JCK test specific. We just happened to hit “codecache full” there.

“jck_simple_api” is a subset of the api suite we compiled for our own purposes. The tests contained therein are just “simple” tests: they do not run too long, they can run massively parallel, they do not depend on specific resources (like ports, addresses, …).

I’m afraid this doesn’t help you much. At least I tried. �� If you can’t reproduce on your own, please let us know what tracing you need. We could then try to produce the output on our test systems.

Thanks,
Lutz

From: Liu Xin <navy.xliu at gmail.com>
Date: Friday, 17. August 2018 at 17:15
To: "Haug, Gunter" <gunter.haug at sap.com>
Cc: "hotspot-runtime-dev at openjdk.java.net" <hotspot-runtime-dev at openjdk.java.net>, Lutz Schmidt <lutz.schmidt at sap.com>, "Doerr, Martin (martin.doerr at sap.com)" <martin.doerr at sap.com>, "xxinliu at amazon.com" <xxinliu at amazon.com>
Subject: Re: RFR (XS): 8208480: Fix for test failure: assert(is_bound() || is_unused()) after JDK-8206075 in C1

hi, Gunter,
I do consider bailout case. why didn't it catch your case?
c1_LIRAssember.hpp
 // unified bailout support
  void bailout(const char* msg) {
    // reset the label in case it hits assertion in destructor.
    _unwind_handler_entry.reset();
    compilation()->bailout(msg);
  }

can I reproduce this jck_simple_api_work?
/priv/jvmtests/output_sapjvm12_o_jdk-test_dbgU_linuxs390x/jck_simple_api_work/hs_err_pid108809.log

On Fri, Aug 17, 2018 at 6:39 AM Haug, Gunter <gunter.haug at sap.com<mailto:gunter.haug at sap.com>> wrote:
Hi all,

could I please have  a review and a sponsor for this tiny fix:

https://bugs.openjdk.java.net/browse/JDK-8208480
http://cr.openjdk.java.net/~ghaug/webrevs/8208480

C1 holds a label to the unwind handler during compilation. There are bail-out paths where a branch to this label has already been emitted but the handler hasn't (e.g. code cache full). The label is therefore unbound when the destructor is invoked and the assertion fires.

Thanks,
Gunter