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

[David Holmes]

Just adding my 2c in one place as I'm not looking at this in detail ...

On 7/08/2018 12:18 PM, Kim Barrett wrote:
>> On Aug 6, 2018, at 12:39 PM, Gerard Ziemski <gerard.ziemski at oracle.com> wrote:
>>> src/hotspot/share/utilities/globalCounter.cpp
>>> 64   // Handle bootstrap
>>> 65   if (Threads::number_of_threads() == 0) {
>>> 66     return;
>>> 67   }
>>>
>>> What is this about?  number_of_threads only refers to Java threads,
>>> but the iteration should deal with there being none, right?  Or does
>>> this get called so early (because of SymbolTable changes) that even
>>> that iteration setup doesn't work?
>>>
>>> If not that, then maybe we're calling before the VMThread exists, and
>>> that's the real problem?  In which case a different test, differently
>>> located, seems necessary.
>>
>> We needed it when I was bringing up the code and I tried removing it to see whether we still need it and it seems that we do (details on the crash in the bug itself). Maybe Robbin can shed more light here?
> 
> The problem here is that we're using the StringTable (and therefore
> GlobalCounter) before the main thread has been registered.  That
> registration happens in create_vm() (Threads::add(main_thread), line
> 3729), which follows the call to init_globals() (where the symbol
> table usage is occurring) in create_vm().
> 
> Maybe moving the Threads::add earlier would fix the problem?  But this
> initialization code is very ordering sensitive, so I don't know if
> that would work.

I'd suggest not attempting that. It might appear to work only for the 
bugs to become apparent much later.

I think this early VM usage needs to be pushed down to the SMR code to 
handle correctly, rather than hacking an initialization check into the 
GlobalCounter code.

David
-----