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

[David Holmes]

On Tue, 25 May 2021 21:48:48 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> Yes, 32 doesn't seem right.
>
>> We need @fisk to time in here with his rationale from the beginning of the Thread-SMR project.
>> 
>> 
>> 
>> The 1031 came from me and I stole it from some other fixed hash table size in the VM.
>> 
>> 
>> 
>> Someone please correct me if I'm wrong, but doesn't this hash_table_size value max out
>> 
>> at 64? `MIN2((int)threads->length(), 32)` => `32` when there are more than 32 threads
>> 
>> and `32 << 1` => `64`.
>> 
>> 
>> 
>> Yeah, we really need @fisk to chime in here.
>> 
>> 
>> 
>> Also, don't forget that these hash_tables are very, very short lived
>> 
>> since they only exist while we are gathering either hazard ptrs or
>> 
>> JavaThread* protected by hazard ptrs.
>> 
>> 
> 
> I don't recognize the arbitrary 32 limit. If I did indeed write that (I have no recollection), then the only reason for it that I can think of is that hazard pointers are (or were?) very infrequent to encounter and that most of the time, we end up adding no entries at all to the table. And that it would be somehow wasteful to allocate large tables only to not put anything into it.
> 
> But yeah, wouldn't mind getting rid of this arbitrary heuristic limit. I don't think it matters today.

So the "dynamic" aspect of this is not a long-lived table that needs to grow/shrink, but simply that we want to size each short-lived table more appropriately rather than all being sized at 1031.

Very unclear what potential performance implication of this change could be.

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

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