RFR: 8367993: G1: Speed up ConcurrentMark initialization

Leo Korinth lkorinth at openjdk.org
Tue Dec 9 15:04:11 UTC 2025


This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`.  Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads.

It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads.

This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253.

I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look.

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

Depends on: https://git.openjdk.org/jdk/pull/28719

Commit messages:
 - 8367993: G1: Speed up ConcurrentMark initialization

Changes: https://git.openjdk.org/jdk/pull/28723/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367993
  Stats: 97 lines in 10 files changed: 53 ins; 21 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/28723.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723

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


More information about the hotspot-dev mailing list