RFR: 8191786: Thread-SMR hash table size should be dynamic

[David Holmes]

On Mon, 24 May 2021 16:06:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Small change to switch Thread-SMR's hash table from ResourceHashtable to KVHashtable
> so that a variable sized hash table is used instead of a fixed size hash table (1031 elements).
> Also refactor common hash table size calculation code into static hash_table_size()
> function and call it from both places.
> 
> Test with Mach5 Tier[1-7] testing.

Hi Dan,

What is the motivation behind this? What do we see happen with the current HT if we have too many threads? What will happen with the new HT when it has to resize - will we see a pause while that happens?

The mechanics of the change seem okay. A couple of queries on ergonomics choices.

Thanks,
David

src/hotspot/share/runtime/threadSMR.cpp line 204:

> 202:   //   "BasicHashtable<(MEMFLAGS)2>::new_entry(unsigned int)", referenced from:
> 203:   //   KVHashtable<void*, bool, (MEMFLAGS)2, &(unsigned int primitive_hash<void*>(void* const&)), &(bool primitive_equals<void*>(void* const&, void* const&))>::add_if_absent(void*, bool, bool*) in threadSMR.o
> 204:   //

We don't need these details in the comment.

src/hotspot/share/runtime/threadSMR.cpp line 854:

> 852: 
> 853: // Hash table size should be first power of two higher than twice the
> 854: // length of the ThreadsList

What is the basis for this? Seems reasonable for small numbers of threads but excessive for large numbers.

src/hotspot/share/runtime/threadSMR.cpp line 857:

> 855: static int hash_table_size() {
> 856:   ThreadsList* threads = ThreadsSMRSupport::get_java_thread_list();
> 857:   int hash_table_size = MIN2((int)threads->length(), 32) << 1;

Doesn't this start things off a bit small. If the old size was 1031 why not start in that area?

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

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