Scoping the stack allocation prototype for C2

[Reingruber, Richard]

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