RFR: 8315559: Delay TempSymbol cleanup to avoid symbol table churn [v4]

[Kim Barrett]

On Wed, 1 Nov 2023 18:12:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thanks. Is the 'leak' is relevant in this case since we're shutting down anyway? I tried draining the queue in before_exit but that doesn't seem to run with ctrl-c/SIGINT shutdowns.
>> 
>>> HotSpot code avoids variables with static storage duration for types with
>> non-trivial construction or destruction
>> 
>> Do you have a suggested alternative? Everything in symbol table seems to be static.
>
> I've filed a bug report against the style guide to provide guidance in this area.
> https://bugs.openjdk.org/browse/JDK-8319242
> 
> We typically define a variable with a pointer type, and initialize it somewhere in the VM startup process.  So in
> this case, something like
> 
> // declared in class
> static TempSymbolDelayQueue* _cleanup_delay;
> 
> // in the .cpp
> TempSymbolDelayQueue* SymbolHandleBase::_cleanup_delay = nullptr;
> // and update uses accordingly.
> 
> Also declare and define an initialization function to initialize that variable, and call it somewhere in init.cpp,
> probably in init_globals().  Use the style that exists there.  I expect if you don't put it early enough that you'll
> reliably get an obvious crash from attempting to access a nullptr.

As you suggest, in this case the "leak" doesn't matter because we're on the
way to shutdown. One might think the asserts could be conditionalized on that,
but so far as I know there isn't a reliable "on the way to shutdown" detector.
The idiom described above is what's done throughout HotSpot for initialization
(to ensure we have control of initialization order, among other things), and
we often don't worry about the teardown side of things.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16398#discussion_r1379171154