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

[Roland Westrelin]

On Fri, 18 Feb 2022 10:11:37 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into JDK-8275201
>>  - Merge branch 'master' into JDK-8275201
>>  - build fix
>>  - Merge branch 'master' into JDK-8275201
>>  - whitespaces
>>  - remove klass accessor
>
> 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()`.

I enhance is_reference_type() but it's called from so many locations that it's hard to tell if simply accepting T_NARROWOOP works for all uses. So I also added a boolean parameter.

> 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?

I don't think that would work. The type of the element of `new I[]` is a TypeInstPtr. If I is an interface, that TypeInstPtr must not be Object. In any case, this will become cleaner with the next change where the instance klass and interfaces are recorded separately in TypeInstPtr.

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

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