RFR(S): 8214352: C1: Unnecessary "compilation bailout: block join failed" with JVMTI

[Doerr, Martin]

Hi Igor,

thank you for looking at my proposal.
Let me try to explain it by a schematic example.

Block 1
local 1 used for some object (assignment and usage)

Block 2
local 1 used for an int (assignment and usage)
loop: if ... goto Block 2

C1 creates a Phi function (with input local 1 of type object) when looking at the edge from Block 1 to Block 2 (GraphBuilder::iterate_bytecodes_for_block => BlockBegin::try_merge => setup_phi_for_local).
When looking at the backedge (the loop in Block 2), BlockBegin::try_merge sees the "existing_value" of type object and the "new_value" of type int coming from the backedge.
This is the point at which we know that we are beyond the life ranges of local l. It's dead because a life local can't have conflicting types.

I think the appropriate treatment is to invalidate the local and the Phi function. Seems like an old version had already done this according to the comment "The old code invalidated the phi function here" probably because linear scan had issues and the problematic case was rare enough (without JVMTI). But now we have a bailout in LIRGenerator::move_to_phi which handles the really problematic case, so we can use the invalidation in BlockBegin::try_merge again which is far better when using JVMTI.

AFAIK, this matches what C2 would do.

Hope this makes it more clear. Let me know if I missed anything.

Thanks and best regards,
Martin


From: Igor Veresov <igor.veresov at oracle.com>
Sent: Dienstag, 4. Dezember 2018 18:13
To: Doerr, Martin <martin.doerr at sap.com>
Cc: Vladimir Kozlov <vladimir.kozlov at oracle.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(S): 8214352: C1: Unnecessary "compilation bailout: block join failed" with JVMTI

So how and why does it happen that a phi has different input types?

igor





On Dec 3, 2018, at 2:24 AM, Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>> wrote:

Hi Vladimir,

thanks for reviewing. I hope a C1 expert can find some time to take a look.

Best regards,
Martin


-----Original Message-----
From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net<mailto:hotspot-compiler-dev-bounces at openjdk.java.net>> On Behalf Of Vladimir Kozlov
Sent: Sonntag, 2. Dezember 2018 01:50
To: hotspot-compiler-dev at openjdk.java.net<mailto:hotspot-compiler-dev at openjdk.java.net>
Subject: Re: RFR(S): 8214352: C1: Unnecessary "compilation bailout: block join failed" with JVMTI

Seems fine to me but I am not C1 expert.

Regards,
Vladimir

On 11/27/18 3:03 AM, Doerr, Martin wrote:

Hi,

C1 currently bails out when a local value is derived from a Phi with different types.

According to comments, this case is supposed to be very rare, but it's not so rare when a JVMTI agent is used
(capability "can_access_local_variables").

I'd like to fix this.

Issue with more detailed description:

https://bugs.openjdk.java.net/browse/JDK-8214352

Webrev:

http://cr.openjdk.java.net/~mdoerr/8214352_c1_phi/webrev.00/
<http://cr.openjdk.java.net/%7Emdoerr/8214352_c1_phi/webrev.00/>

Patch successfully ran through a substantial amount of tests with enabled "can_access_local_variables". Please review.

Best regards,

Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20181204/72548acf/attachment-0001.html>