Scalability bottleneck in SymbolTable::lookup_common()

Symbol table lookup had an optimization added when the symbol table was split into a shared table (for CDS?) and a dynamic table. The optimization tries to track which table successfully found a symbol, so it can try that table first the next time.

At startup time, most symbols will be from the shared table, but over time lookup can will be from a mix of dynamic 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.

Symbol table lookup is used in many JVM operations, including classloading, serialization, and reflection.

In some cases the regression can be seen in the SPECjvm serial benchmark