RFR: 8275201: C2: hide klass() accessor from TypeOopPtr and typeKlassPtr subclasses

[Vladimir Ivanov]

On Mon, 6 Dec 2021 09:59:44 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Outside the type system code itself, c2 usually assumes that a
> TypeOopPtr or a TypeKlassPtr's java type is fully represented by its
> klass(). To have proper support for interfaces, that can't be true as
> a type needs to be represented by an instance class and a set of
> interfaces. This patch hides the klass() accessor of
> TypeOopPtr/TypeKlassPtr and reworks c2 code that relies on it in a way
> that makes that code suitable for proper interface support in a
> subsequent change. This patch doesn't add proper interface support yet
> and is mostly refactoring. "Mostly" because there are cases where the
> previous logic would use a ciKlass but the new one works with a
> TypeKlassPtr/TypeInstPtr which carries the ciKlass and whether the
> klass is exact or not. That extra bit of information can sometimes
> help and so could result in slightly different decisions.
> 
> To remove the klass() accessors, the new logic either relies on:
> 
> - new methods of TypeKlassPtr/TypeInstPtr. For instance, instead of:
> toop->klass()->is_subtype_of(other_toop->klass())
> the new code is:
> toop->is_java_subtype_of(other_toop)
> 
> - variants of the klass() accessors for narrower cases like
>   TypeInstPtr::instance_klass() (returns _klass except if _klass is an
>   interface in which case it returns Object),
>   TypeOopPtr::unloaded_klass() (returns _klass but only when the klass
>   is unloaed), TypeOopPtr::exact_klass() (returns _klass but only when
>   the type is exact).
> 
> When I tested this patch, for most changes in this patch, I had the
> previous logic, the new logic and a check that verified that they
> return the same result. I ran as much testing as I could that way.

Nice work, Roland! Looks good.

Except IGP-related crashes, all tests passed (hs-tier1 - hs-tier9).

Also, you need to merge it with #6952.

Some minor cleanup suggestions follow.

src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 800:

> 798:   } else if (src_type->isa_aryptr()) {
> 799:     BasicType src_elem = src_type->isa_aryptr()->elem()->array_element_basic_type();
> 800:     if (is_reference_type(src_elem) || src_elem == T_NARROWOOP) {

I find numerous new `T_NARROWOOP` checks distracting. Is it possible to get rid of them?
E.g., either normalize it to `T_OBJECT` in `array_element_basic_type()` or enhance `is_reference_type()`.

src/hotspot/share/opto/idealGraphPrinter.cpp line 490:

> 488:       const TypeInstPtr  *toop = t->isa_instptr();
> 489:       const TypeInstKlassPtr *tkls = t->isa_instklassptr();
> 490:       if (toop->is_interface() || tkls->is_interface()) {

Missing NULL checks on `toop` and `tkls`. It causes crashes when IGP is enabled.

src/hotspot/share/opto/macro.cpp line 685:

> 683:   int element_size = 0;
> 684:   BasicType basic_elem_type = T_ILLEGAL;
> 685:   const Type *field_type = NULL;

Typo: should be `const Type* field_type`.

src/hotspot/share/opto/macro.cpp line 744:

> 742:             field_type = TypeInstPtr::BOTTOM;
> 743:           } else if (field != NULL && field->is_static_constant()) {
> 744:             // This can happen if the constant oop is non-perm.

Seems like the comment is outdated. What is 'non-perm'? Out of PermGen?

src/hotspot/share/opto/type.hpp line 1198:

> 1196:   // Instance klass, ignoring any interface
> 1197:   ciInstanceKlass* instance_klass() const {
> 1198:     if (klass()->is_loaded() && klass()->is_interface()) {

Does it make sense to normalize `_klass` during construction instead?

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

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