Updated SoV documents

[Tobias Hartmann]

Hi Brian,

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

Best regards,
Tobias