Scoping the stack allocation prototype for C2

[Nikola Grcevski]

Hi Richard,

Thanks for your suggestion. We have started looking at this and once we 
have the allocation hoisting prototype ready, we'll measure it against what
we get with the stack allocation patch.

Once we have some results we'll share them here.

We are open to more suggestions from you or anyone else in the community.

Thanks,
Nikola and Charlie

-----Original Message-----
From: Reingruber, Richard <richard.reingruber at sap.com> 
Sent: July 29, 2020 3:52 AM
To: Charlie Gracie <Charlie.Gracie at microsoft.com>; Erik Österlund <erik.osterlund at oracle.com>; Nikola Grcevski <Nikola.Grcevski at microsoft.com>; hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>
Subject: RE: Re: Scoping the stack allocation prototype for C2

Hi,

an even simpler optimization could be to find allocations that don't escape a loop body, schedule them into a dominating region and reuse the allocated bytes in the loop body.

This would be possible without special allocation zones/buffers.

At first glance this seems to be comparatively simple, but still effective.

Again a lot would depend on inlining: will hot allocations be compiled together with their loop?

And I'd think that there have to be hot allocations in the benchmark for stack allocation to be beneficial. If they are not hot then young gen allocation/reclamation are probably good enough.

Maybe the allocation could even be undone after the loop if there was no escaping allocation in the loop. I guess this is the downside: no implicit free when the compiled method returns.

Best regards,
Richard.

-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.java.net> On Behalf Of Charlie Gracie
Sent: Montag, 27. Juli 2020 21:24
To: Erik Österlund <erik.osterlund at oracle.com>; Nikola Grcevski <Nikola.Grcevski at microsoft.com>; hotspot-dev Source Developers <hotspot-dev at openjdk.java.net>
Subject: Re: Re: Scoping the stack allocation prototype for C2

    Hi Erik, 
 
> It sounds like the high level goal is not "allocate on the stack", but  
> rather allocate and free objects more efficiently based on compile-time  knowledge about their scoped lifetime.
 
Yes, you are correct. That is the best way to describe our high-level goal. 
 
> Since I can see so many advantages with this approach, and not really 
> any disadvantages if done right, I wonder if there are any clear 
> reasons not to build it in that (general) way instead.I am curious to hear your thoughts about this.
>
> If you agree this is probably a better way of achieving the same 
> thing, then I have some ideas how best to implement it that we could discuss.
> But maybe we should settle on the direction first instead.Perhaps 
> there are some nice quirks with stack allocations that still make them more desirable, even though I can not currently see it.
 
You have made excellent points about the pros and cons of both solutions, along with Vladimir and others.
Taking all this information into account, we agree that the zone-based approach would satisfy our high-level goals without as many limitations as the stack based approach.
 
> If you agree this is probably a better way of achieving the same 
> thing, then I have some ideas how best to implement it that we could discuss.
 
We would appreciate hearing your ideas about how to best implement the zone-based solution. We are especially interested in your thoughts on how to get started with acquiring a zone and managing it. Having some guidance on the starting the zone-based approach would help us a lot. 
 
Thanks again for your insightful comments, Charlie & Nikola