RFR: 8375359: Improve GC serviceability init staging

[David Holmes]

On Mon, 26 Jan 2026 12:55:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Is there a way to restructure the code so that we don't get more locations in the VM initialization code (external to the GC code) that call various CollectedHeap initialization functions?
>> 
>> I haven't fully looked at this in all details, but could the various `initialize_serviceability` function be called from within the `<GC>CollectedHeap::initialize` function instead?
>
>> Is there a way to restructure the code so that we don't get more locations in the VM initialization code (external to the GC code) that call various CollectedHeap initialization functions?
> 
> I have not looked deeply, but honestly, I doubt it would not introduce more bootstrapping issues. As it stands now, we are changing the init sequence only a little bit, and already when the rest of the system is initialized. Moving serviceability inits way up to `CollectedHeap::initialize` moves it before a lot of other inits, so there is IMO a risk there. Bootstraping sequence is fiddly and always comes with surprises. 
> 
> For example, AFAICS, after `CollectedHeap::initialize` completes, we have not yet initialized Metaspace including its perf counters, String table is not yet wired up, etc. It is plausible serviceability code would need some of that, maybe is some future changes.
> 
> So I'd prefer to keep the patch as it is.

@shipilev I took a look at this but it is not code I know anything about. Hard to determine what the implications of moving these pieces of code around could be. Sorry.

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

PR Comment: https://git.openjdk.org/jdk/pull/29254#issuecomment-3808940265