RFR: Loom compile times

[Stefan Karlsson]

On Wed, 16 Mar 2022 10:54:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> It takes almost double the time to compile HotSpot in the Loom repository compared to the mainline. One source of this regression is the include of the *CollectedHeap.inline.hpp files in the *BarrierSet.inline.hpp files, needed to inline the requires_barriers call all the way down to the GC implementations. 
> 
> This patch removes the inlining and calls the virtual calls instead. This recuperate most of the lost compilation speed, but not quite all (still about a 20% regression). I've verified with a small micro that this doesn't increase the freeze/thaw times. In fact, it increased the performance slightly. Comparing the generated code, I see that the inlined code had two branches and made a jump to the fast path (and not the expected slow path). With the non-inlined call there's only one branch and the fast-path is right after the check.
> 
> The two patches on top of the fix just removes infrastructure that isn't needed when this has been removed.

I've been asked to make a minimal change that keeps the ConfigT class. I'll publish a new PR.

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

PR: https://git.openjdk.java.net/loom/pull/104