RFR: 8288537: Refactor hotspot/share/memory/iterator.hpp

[Ioi Lam]

On Thu, 16 Jun 2022 08:11:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Even though the name sounds generic, the Devirtualizer class was written to support the oop_iterate / OopIterateClosure devirtualization. (Maybe a hint that this should be renamed)
> 
> This patch splits the implementation of this devirtualization into two different files. I think that's unfortunate. I'd rather see that we kept that code together. Maybe move all the code into a new oopIterateClosure.inline.hpp file.
> 
> However, if you do so, you'll find that we would almost move all the code out of iterator.inline.hpp. To me that makes it unclear how much the move of the Devirtualizer contributed to the fixed compilation time.
> 
> Since this patch moves two completely separate closures, could you repurpose this PR to only move the SerializeClosure, so that we can evaluate the move of the OopIterateClosure separately?

The main problem is:

- Devirtualizer inline functions are simpler, but they are needed by many object files
- OopIterateClosure inline functions are complex (and have lots of dependencies, due to the expansion of `OopOopIterateDispatch::Table::Table()`), but they are needed by very few object files

Here's the output of https://urldefense.com/v3/__https://github.com/iklam/tools/blob/main/headers/whoincludes.tcl__;!!ACWV5N9M2RV99hQ!PwCrsqzCaEUD7fa9KqHgab_l8eJxF6NukrKgikTQ__WL2qnxtbl7aJdFw4PUHa_vUOUaAQa04_ahltyq8pePug$ :

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

PR: https://git.openjdk.org/jdk/pull/9176