Updated SoV documents

[Brian Goetz]

> 3. JVM Model:
>> However, because the JVM knows that inline objects do not have identity, it can routinely optimize layout (flattening), instantiation, member access, and calling conventions (scalarization) for inline objects.
> 
> We mostly use the term "scalarization" to describe that inline objects are "passed as fields" in the
> scope of a method. Performance-wise this is the more important optimization compared to the calling
> convention (see https://mail.openjdk.java.net/pipermail/valhalla-dev/2019-December/006668.html). I
> would therefore suggest to differentiate between scalarization in the scope of a method (and it's
> inlinees) and scalarization at method boundaries (i.e., the calling convention optimizations).

By “scalarization in the scope of a method”, you mean ordinary field hoisting?  Since that is an optimization we do routinely for final fields, I had assumed that it was only scalarization at method boundaries the was important and new here?

> 4: Translation scheme:
>> class C extends A implements I { }
> 
> Shouldn't C be declared as "inline class C"?
> Otherwise, it would be ref-default which wouldn't create C$val, right?

Yes.  

There’s also a small error about ref-default inline classes; the ref projection has to be called C, not C$ref, for binary compatibility purposes.

> 
>> now we have a new translation target, one which can routinely optimize layout, instantiation, and calling conventions for inline classes and their reference projections
> 
> What kind of optimizations do you expect for reference projections of inline classes?

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.)