RFR: Loom compile times minimal
    Stefan Karlsson 
    stefank at openjdk.java.net
       
    Wed Mar 16 13:41:11 UTC 2022
    
    
  
(Minimal version of PR #104)
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.
-------------
Commit messages:
 - Keep using ConfigT
 - Stop inlining BS requires_barriers
Changes: https://git.openjdk.java.net/loom/pull/105/files
 Webrev: https://webrevs.openjdk.java.net/?repo=loom&pr=105&range=00
  Stats: 102 lines in 13 files changed: 25 ins; 75 del; 2 mod
  Patch: https://git.openjdk.java.net/loom/pull/105.diff
  Fetch: git fetch https://git.openjdk.java.net/loom pull/105/head:pull/105
PR: https://git.openjdk.java.net/loom/pull/105
    
    
More information about the loom-dev
mailing list