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

Tobias Hartmann tobias.hartmann at oracle.com
Fri Oct 22 08:12:14 UTC 2021


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://urldefense.com/v3/__http://aka.ms/LearnAboutSenderIdentification.*__;XQ!!ACWV5N9M2RV99hQ!dAOsfMX9ydvR6gfkGV1WmFAUGqf_46K5Fe4F-5n902K_qjvnaogKtYqQEHd52Y2O6UE$>
> 
>> 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


More information about the hotspot-dev mailing list