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

[Derek White]

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.

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

Commit messages:
 - Added comment for shift to searching local table first. NUmber based on traces of symboltable lookup failures during javac compilation
 - fix spaces
 - JDK-8276662

Changes: https://git.openjdk.java.net/jdk/pull/6400/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6400&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276662
  Stats: 13 lines in 1 file changed: 9 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6400.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6400/head:pull/6400

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