RFR (L) JDK-8195100: Use a low latency hashtable for SymbolTable

[Gerard Ziemski]

Please review this Enhancement, which uses the new concurrent hash table for SymbolTable.

This is an effort similar to the one behind JDK-8195097 "Make it possible to process StringTable outside safepoint” from a while ago.

The main expected goal here is to eliminate safepoint pauses needed to cleanup the table. This goal was achieved by using “Service Thread” to do the cleaning. Checking whether we need to clean is performed on “VM Thread”, after class unloading (we check the entire table). We also check the bucket into which we happen to be inserting a new item.

A few things to note:

- The SymbolTable implementation follows closely that of StringTable - we might be able to factor out common code later

- There are a few small, but statistically significant, regressions in startup benchmarks (around 2-5%) that will be addressed later, tracked by JDK-8208142

- There is an outstanding question about whether we can safely walk the table during a safepoint using do_scan, but without locking, tracked by JDK-8208462

- There is a cleanup opportunity presented now to remove rehashable hash table, tracked by JDK-8208519 

- There is a new test that validates that we free dead entries when we insert new symbols (using short lived symbols via Class.forName() API)


Tested using Mach5 hs-tier1,2,3,4,5 (final test running right now…)

Webrev: http://cr.openjdk.java.net/~gziemski/8195100_rev1/

Bug: https://bugs.openjdk.java.net/browse/JDK-8195100


Cheers