[External] : Re: RFC - Improving C2 Escape Analysis

[Cesar Soares Lucas]

Hi Tobias,

Thank you for the feedback. Very much appreciated.

> I think the most critical issue is that current EA does not properly handle even "simple" control
> flow merges (including the cases you described in the "Re-use Stack Slots" section). I.e., cases
> where the object does not escape on any paths but control flow is too complicated for EA to prove
> that. Often, it's not even multiple objects of the same type that are merged but just a single
> object that is used in different paths.

Right. I was suspecting this to be the most critical issue indeed. However, I
didn't know there was a case where "... the object does not escape on any paths
but control flow is too complicated for EA to prove that." Is this an issue
tracked in JBS or perhaps you can show me an example where this happens?

> Maybe the inability to handle `null` could be described/handled as a separate issue. IIRC both EA
> and scalarization do not support `null` being merged with a non-escaping object.

Got it. I stumbled on this recently; at least I think this is what I found.
This seems to be a big pain point.

> Also, I think there are (or will be) cases when EA is able to prove that an object is non-escaping
> but scalarization still fails. For example, if not all loads can be folded or there are other uses
> left (see `PhaseMacroExpand::can_eliminate_allocation`). Since scalarization is the main benefit of
> EA, improvements to EA need to be made to scalarization as well.

Got it, makes perfect sense to me. So far, this didn't show up in my
"quantitative analysis" as a big problem because most of the objects are
considered "GlobalEscape".


Regards,
Cesar



________________________________
From: Tobias Hartmann <tobias.hartmann at oracle.com>
Sent: October 22, 2021 1:12 AM
To: Cesar Soares Lucas <Divino.Cesar at microsoft.com>; Ron Pressler <ron.pressler at oracle.com>
Cc: John Rose <john.r.rose at oracle.com>; Mark Reinhold <mark.reinhold at oracle.com>; hotspot-dev at openjdk.java.net <hotspot-dev at openjdk.java.net>; Brian Stafford <Brian.Stafford at microsoft.com>; Martijn Verburg <Martijn.Verburg at microsoft.com>
Subject: Re: [External] : Re: RFC - Improving C2 Escape Analysis

Hi Cesar,

On 22.10.21 01:07, Cesar Soares Lucas wrote:
> We decided to direct our immediate efforts to improving EA for heap objects.
> AFAIU inline types will bring a lot of performance improvements but that will
> require the programmer to rewrite part(s) of the application - please correct
> if I'm wrong here. We are investigating how we can improve the performance of
> applications that aren't updated to use inline types.

That makes perfect sense to me.

> About the write-up, may I ask you what do you think is the most critical
> issue raised there?

I think the most critical issue is that current EA does not properly handle even "simple" control
flow merges (including the cases you described in the "Re-use Stack Slots" section). I.e., cases
where the object does not escape on any paths but control flow is too complicated for EA to prove
that. Often, it's not even multiple objects of the same type that are merged but just a single
object that is used in different paths.

> Or perhaps there is something else that we missed?

Maybe the inability to handle `null` could be described/handled as a separate issue. IIRC both EA
and scalarization do not support `null` being merged with a non-escaping object.

Also, I think there are (or will be) cases when EA is able to prove that an object is non-escaping
but scalarization still fails. For example, if not all loads can be folded or there are other uses
left (see `PhaseMacroExpand::can_eliminate_allocation`). Since scalarization is the main benefit of
EA, improvements to EA need to be made to scalarization as well.

Best regards,
Tobias


> ----------------------------------------------------------------------------------------------------
> *From:* Ron Pressler <ron.pressler at oracle.com>
> *Sent:* October 19, 2021 6:39 AM
> *To:* Tobias Hartmann <tobias.hartmann at oracle.com>
> *Cc:* Cesar Soares Lucas <Divino.Cesar at microsoft.com>; John Rose <john.r.rose at oracle.com>; Mark
> Reinhold <mark.reinhold at oracle.com>; hotspot-dev at openjdk.java.net <hotspot-dev at openjdk.java.net>;
> Brian Stafford <Brian.Stafford at microsoft.com>; Martijn Verburg <Martijn.Verburg at microsoft.com>
> *Subject:* Re: RFC - Improving C2 Escape Analysis
>
> [You don't often get email from ron.pressler at oracle.com. Learn why this is important at
> http://aka.ms/LearnAboutSenderIdentification.]
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification.*__%3BXQ!!ACWV5N9M2RV99hQ!dAOsfMX9ydvR6gfkGV1WmFAUGqf_46K5Fe4F-5n902K_qjvnaogKtYqQEHd52Y2O6UE%24&data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cebebdc34c4d1498ad57108d99533af9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637704871503272088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jUHtFaV8cWBhHuEZRXYBjTOprd2Bh0%2FFO2nXtQf%2FW84%3D&reserved=0>
>
>> On 19 Oct 2021, at 14:17, Tobias Hartmann <tobias.hartmann at oracle.com> wrote:
>>
>>
>> That said, support for stack/thread local allocation would be something that we could potentially
>> use in Valhalla to avoid buffering on the heap. It's difficult though because in most cases we use
>> buffering when storing to a non-flattened field that escapes to other threads.
>>
>
>
> Just a reminder, stacks can move in memory (virtual threads), so great care must be
> taken with pointers pointing into the stack. As a general rule, that’s a no-no.
>
> — Ron