RFR: 8266550: C2: mirror TypeOopPtr/TypeInstPtr/TypeAryPtr with TypeKlassPtr/TypeInstKlassPtr/TypeAryKlassPtr [v2]

[Roland Westrelin]

On Mon, 7 Jun 2021 14:06:05 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> I started reviewing the patch.

Thanks!
> 
> Can you, please, elabroate on design goals of the patch?
> I don't fully understand the intended relation between `TypeInstKlassPtr`, `TypeAryKlassPtr`, and `TypeKlassPtr`.

On the oop side, TypeOopPtr is the super type for TypeInstPtr and TypeAryPtr. Type*KlassPtr are intended to work the same.
To keep track of interfaces, a TypeInstPtr will need an extra field that contains the set of interfaces that it implements.
A TypeAryPtr implements some interfaces (Cloneable etc.). If its elements are objects, its elements may implement interfaces too. A TypeAryPtr has a TypeAry field that references a TypeOopPtr for object arrays. Interfaces implemented by the array elements are attached to that TypeOopPtr.

Now with only a TypeKlassPtr where do we record interfaces implemented by array elements?

The motivation of this change is to mirror the structure described above with TypeOopPtr on the TypeKlassPtr and to have somewhere to store interfaces for object arrays.

> My observations so far:
> 
> * `Type::base()` can never be `Type::KlassPtr` anymore: it's either `InstKlassPtr` or `AryKlassPtr`; all `t->base() == Type::KlassPtr` should be replaced by `t->base() == Type::InstKlassPtr || t1->base() == Type::AryKlassPtr`;

I don't think that's true: roughly TypeAryKlassPtr meets TypeInstKlassPtr would give a TypeKlassPtr (same as TypeAryPtr meets TypeInstPtr gives a TypeOopPtr).

> * `java.lang.Object` is represented with `InstKlassPtr` (`TypeInstKlassPtr::OBJECT`) and as a consequence type flattening can turn `TypeAryKlassPtr` into `TypeInstKlassPtr`.

That should again be the same as what's going on with TypeOopPtr/TypeInstPtr/TypeAryPtr.

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

PR: https://git.openjdk.java.net/jdk/pull/3880