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

David Holmes david.holmes at oracle.com
Wed May 26 01:23:33 UTC 2021


Hi Dan,

On 26/05/2021 5:48 am, Daniel D.Daugherty wrote:
> On Tue, 25 May 2021 01:10:37 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> What is the motivation behind this?
> 
> Finishing code that was left incomplete by the Thread-SMR project. We either
> get rid of the hash_table_size calculations (from two places) in the base code
> or we switch to a Hashtable that supports specifying a size at runtime instead
> of compile time.

Okay - removing the unused code would be a less disruptive change in 
that case.

> 
>> What do we see happen with the current HT if we have too many threads?
> 
> We haven't seen any problems with the current code. I'm just cleaning up this
> long standing piece of work.
> 
> 
>> What will happen with the new HT when it has to resize - will we see a
>> pause while that happens?
> 
> These Thread-SMR hash tables don't resize. They are created and live for
> a very short time. They contain either hazard ptrs or they contain JavaThread*
> that are protected by hazard ptrs.
> 
> ThreadsSMRSupport::free_list() creates a ThreadScanHashtable of the
> current hazard ptrs (there typically are not very many of these).
> 
> ThreadsSMRSupport::is_a_protected_JavaThread() creates a
> ThreadScanHashtable of JavaThread* that are protected by the
> current hazard ptr in use by the system.
> 
> Both of these ThreadScanHashtable objects only live as long as the
> function that created them, i.e., not long.

Okay I get the "dynamic" aspect of this now.

Thanks,
David

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


More information about the hotspot-runtime-dev mailing list