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

[Srikanth Adayapalam]

On Thu, 1 Apr 2021 15:43:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

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

I agree with your observation that "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)." So what call out as the problem inherent in the new approach is but one instance of the larger problem that will occur in other contexts. I agree with your suggestion elsewhere that this could be handled on a PR of its own.

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

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