Updated SoV documents
brian.goetz at oracle.com
Mon Mar 30 16:07:47 UTC 2020
>> 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".
>> Basically, better escape analysis is the primary one. If we can prove non-nullity (or confidently speculate on it), I would assume then we can recover the scalarization optimizations, but I understand we haven’t done this (and may not.)
> We actually do this already in the scope of a method (and it's inlinees). If we can prove or
> speculate on non-nullity, we apply the same optimizations to C$ref that would be applied to C$val. I
> wouldn't call this "better escape analysis" though because there is no escape analysis involved.
> However, we don't do this beyond call boundaries (details are explained in ).
> 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.)
More information about the valhalla-dev