RFR: 8261954: Dependencies: Improve iteration over class hierarchy under context class

[Vladimir Ivanov]

On Thu, 18 Feb 2021 22:36:37 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Simplify `ClassHierarchyWalker::find_witness_anywhere()` which iterates over class hierarchy under context class searching for witnesses.
>> 
>> Current implementation traverses the hierarchy in a breadth-first manner and keeps a stack-allocated array to keep a worklist.
>> But all the subclasses are already part of a singly linked list formed by `Klass::subklass()`/`next_sibling()`/`superklass()`.
>> 
>> Proposed refactoring gets rid of the explicit worklist and switches to the traversal over the linked list (encapsulated into `ClassHierarchyIterator`). It performs depth-first pre-order hierarchy traversal. 
>> 
>> (There are some other minor refactorings applied in `ClassHierarchyWalker` along the way.) 
>> 
>> Testing:
>> - [x] hs-tier1 - hs-tier8
>> - [x] additional verification that CHA decisions aren't affected
>
> src/hotspot/share/oops/instanceKlass.hpp line 1486:
> 
>> 1484:   }
>> 1485: };
>> 1486: 
> 
> The _subklass and _next_sibling fields and implementation are in Klass (klass.hpp/cpp) but I always wonder why they are not in InstanceKlass (instanceKlass.hpp/cpp).  If this new class is in instanceKlass.hpp, these fields should be in the same.  If you agree, we should file an RFE and I will move them.  If the fields truly belong in klass.hpp, then this should be there too. ie. they should match.

I think it's `java.lang.Object` which complicates things. All array classes are rooted at Object, so neither `_subklass` nor  `_next_sibling` can be changed to `InstanceKlass`. I put `ClassHierarchyIterator` in `instanceKlass.hpp` primarily because it accepts only `InstanceKlass` root class. But I'm fine with putting it into `klass.hpp`.

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

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