Updated SoV documents
tobias.hartmann at oracle.com
Tue Mar 31 06:53:25 UTC 2020
On 30.03.20 18:07, Brian Goetz wrote:
>>> By “scalarization in the scope of a method”, you mean ordinary field hoisting? Since that is an
>>> optimization we do routinely for final fields,
>> No, I'm basically talking about what C2's -XX:+EliminateAllocations does today for very limited
>> cases of non-escaping object allocations (that's what we call "scalar replacement").
> OK, now I see where we are stumbling over terms.
> Yes, for within-method (or inlinee) scalar replacement, I assume that we can do this better for
> inlines (including reference projections) than we can for identity classes -- this is what I meant
> below by "better escape analysis." I had been folding traditional within-method scalar replacement
> into "escape analysis".
OK, looks like we are on the same page now.
>> You are saying "can routinely optimize layout" but I don't see how we could do this for the
>> reference projections?
> No. In fact, if a field is typed with a reference type, then we should take that as an indication
> of programmer intent that the layout they wanted was a reference, not inlining. So we should not
> attempt to optimize layout at all for reference projections. (Note that I assume the VM is ignorant
> about the concept of reference projection, and just goes on hierarchy analysis and knowledge of
> which types are reference types / identity classes / inline classes.)
Makes sense. I would suggest to slightly rephrase this sentence in the Translation Scheme chapter
then to make it clear that we are not optimizing the layout for reference projections:
> routinely optimize layout [...] for inline classes and their reference projections
More information about the valhalla-dev