[lworld] RFR: 8244227: [lworld] Explore an implementation where the reference projection and value projection types are backed by a single class symbol

[Maurizio Cimadamore]

On Wed, 31 Mar 2021 12:44:17 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> This PR overhauls the existing implementation/representation of reference projection types  and the inline types so that both share the same underlying symbol, much like how an infinite family of parameterized types that originate from the same generic type are modelled using the same underlying symbol.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java line 373:
> 
>> 371:         JCMethodDecl lambdaDecl = make.MethodDef(make.Modifiers(sym.flags_field),
>> 372:                 sym.name,
>> 373:                 make.QualIdent(lambdaType.getReturnType().tsym).setType(lambdaType.getReturnType()),
> 
> Discussion item:This spot indicates one of the pain points in the new approach, There are lots of places where we construct fresh AST nodes from a symbol and in the process decorate the AST's type from what we see in the symbol. This is not a problem for parameterized types because the type arguments are erased by TransTypes anyway. But with Foo.ref and Foo.val sharing the same symbol, we will loose reference "projection'ness". I would like to discuss if there are mechanical ways to  detect and prevent such loss of type information. ATM, I am dependent on tests breaking to expose such problems and this is dependent heavily on coverage and coverage is still in infancy

Again, my test here is this: suppose that here we weren't talking about Point.ref/Point.val - but, instead of List<int> vs. List<float>. Would anything be different? I don't think so. What you are observing is the result of a "wrong" assumption made by the code - or, rather, an assumption that "used to" be true, but is no longer. That is, this code (and code like this spread all over javac) assumes that we can safely ignore type info once we're past the frontend, as code generation is only expressed in terms of erased types (which are also the types attached to the symbol). This assumption is starting to crumble now, and will come crashing down when specialized generics are introduced. So I see this as technical debt (e.g. javac throwing aways types and dealing with symbols too early) as opposed to a specific limitation of the patch proposed in this PR. To get a cleaner fix, we should fix the underlying problem (eager erasure).

-------------

PR: https://git.openjdk.java.net/valhalla/pull/375