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