RFR: 8288537: Move Devirtualizer out of hotspot/share/memory/iterator.hpp

[Ioi Lam]

On Fri, 17 Jun 2022 08:55:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I forgot that Loom hijacked Devirtualizer for the derived oops processing. This devirtualization is not needed. The compiler sees the correct type and performs the correct inlining anyway. Before the integration of Loom I removed the usage of Devirtualizer::do_bit and verified that the compiler generated the same code (though I forgot to remove function).
> 
> I took and tested removing Devirtualizer::do_derived_oops, and again, the compiler generated the same code. So, simplest would be to just remove that function and the include of iterator.inline.hpp. However, if you still want to do this separation, then I guess that's OK as well. Could you move the Devirtualizer class to utilities/ instead of oops/, given that it's not necessarily oops that we are visiting? Maybe also update the comment to not mention OopClosureType.
> 
> Sounds good to move the OopIterateDispatch code to oops/oopIterateDispatch.

I think it's still useful to move Devirtualizer out in case it might be used in the future by other code. I've backed out the changes related to SerializeClosure, and moved the header to utilities/devirtualizer.hpp.

If you want to do the Loom cleanup, I'll leave it up to you :-)

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

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