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

[Kim Barrett]

On Tue, 31 Oct 2023 12:27:53 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Attempt to fix regressions in class-loading performance caused by fixing a symbol table leak in [JDK-8313678](https://bugs.openjdk.org/browse/JDK-8313678).
>> 
>> See lengthy discussion in https://bugs.openjdk.org/browse/JDK-8315559 for more background. In short, the leak was providing an accidental cache for temporary symbols, allowing reuse.
>> 
>> This change keeps new temporary symbols alive in a queue for a short time, allowing them to be re-used by subsequent operations. For example, when attempting to load a class we may call JVM_FindLoadedClass for multiple classloaders back-to-back, and all of them will create a TempNewSymbol for the same string. At present, each call will leave a dead symbol in the table and create a new one. Dead symbols add cleanup and lookup overhead, and insertion is also costly. With this change, the symbol from the first invocation will live for some time after it is used, and subsequent callers can find the symbol alive in the table - avoiding the extra work.
>> 
>> The queue is bounded, and when full new entries displace the oldest entry. This means symbols are held for the time it takes for 100 new temp symbols to be created. 100 is chosen arbitrarily - the tradeoff is memory usage versus 'cache' hit rate.
>> 
>> When concurrent symbol table cleanup runs, it also drains the queue.
>> 
>> In my testing, this brings Dacapo pmd performance back to where it was before the leak was fixed.
>> 
>> Thanks @shipilev , @coleenp and @MDBijman for helping with this fix.
>
> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adress comments
>   
>   Fix indentation
>   Improve tests
>   Improve comment
>   Remove redundant null check
>   Improve naming
>   Pop when >, not >= max len

Changes requested by kbarrett (Reviewer).

src/hotspot/share/oops/symbolHandle.hpp line 70:

> 68:   static TempSymbolDelayQueue _cleanup_delay;
> 69:   static volatile int32_t _cleanup_delay_len;
> 70:   static volatile int32_t _cleanup_delay_max_entries;

We don't usually use sized types unless the size actually matters.  I don't think it does here.

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

PR Review: https://git.openjdk.org/jdk/pull/16398#pullrequestreview-1708454218
PR Review Comment: https://git.openjdk.org/jdk/pull/16398#discussion_r1378945647