Updated SoV documents

Brian Goetz 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 [1]).
> 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 mailing list