RFR: 8276662: Scalability bottleneck in SymbolTable::lookup_common()

[Claes Redestad]

On Mon, 15 Nov 2021 22:31:13 GMT, Derek White <drwhite at openjdk.org> wrote:

> Symbol table lookup had an optimization added when the symbol table was split into a shared table (for CDS?) and a local table. The optimization tries to track which table successfully found a symbol, so it can try that table first the next time.
> 
> Symbol table lookup is used in many JVM operations, including classloading, serialization, and reflection.
> 
> At startup time, more symbols will be from the shared table, but over time lookup can will be from a mix of local and shared symbols (eg user classes still have java.lang.String fields or subclass from java.lang.Object), resulting in multiple threads fighting over the value of this global variable.
> 
> With enough threads and cores, this can result in "true sharing" cache line contention.
> 
> This fix solves the scalability issue by checking the shared table first "early on", and when enough local symbols have been added, then check the local table first.  
> 
> Other options would also solve the the scaling problem, but may change the behavior that we're trying to optimize, or add more overhead or complexity than warranted, such as:
> - Statically preferring the shared or local table
> - Using a thread-local variable to track which table to search first
> - Using a NUMA-aware set of N variables distributed over M threads.

I agree the hint provided by `_lookup_shared_first` makes more sense as a thread local than global state, and that this particular flag seem a worthwhile `THREAD_LOCAL` candidate even with some potential for footprint overhead.

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

PR: https://git.openjdk.java.net/jdk/pull/6400