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

[Srikanth Adayapalam]

On Wed, 31 Mar 2021 12:53:12 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.
>
> Here are some notes that should help in the review process. I have broken down the changes involved into six logical units each forming a separate commit. Of these, the very first ("In diagnostics and debug strings while mentioning projection types, use .ref/.val rather than $ref/$val") and perhaps even the second commit ("Get out of the business of having to maintain the doppleganger symbol in sync with original") can be skipped or cursorily glanced through.
> 
> Real action starts at the third commit ("Genesis, construction, preservation and propagation of reference projection type") and proceeds through the next three commits.

Overall, I see two major challenges with the new approach (although it is simpler in many ways and has much to like about vis a vis what we have now):

1. Types.asSuper(Type, Symbol) would answer non-null for Foo.ref, Foo.val.tsym being passed in because they both have the same sym and deep down in Types.asSuper we return nonnull if the symbol is equal. So, I have to invent a version of Types.asSuper(Type, Type) instead and reroute the calls to that. However this was tricky in that there are places we do want asSuper to answer non-null when the Type is reference projection and the Symbol is primitive class. For example given Foo<T> { void add(T) {} } a call to Types.memberType(Foo.ref<String>, add(String)) internally results in a call to asSuper(Foo.ref<String>, Foo<T>) -
2.  There are places where we go from Symbol -> AST using the TreeMaker, - these Tree factory methods internally set the AST node type from the symbol. This results in "reference projectionness" being lost. The problem is to mechanically identify the places where such loss may occur (and recover, which is easy to do). ATM, I fixed the places where the tests failed thereby indicating type loss. But this approach is heavily dependent on coverage being good, and our tests are still not super good there being a work in progress (See that 2 is not a problem for parameterized types because after TransType, type arguments are gone AND more importantly the erasure of all parameterized types of the same generic class is the same, whereas we want Foo.ref and Foo.val to share a symbol but erase differently.)

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

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