JDK-8223317 : Need scan without lock for concurrent hash tables
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 13
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2019-05-03
  • Updated: 2020-02-11
  • Resolved: 2020-01-28
Related Reports
Relates :  
Relates :  
Description
In JDK-8185525 we repeat last JFR event if can't gran the lock to scan the table.

It would be nice if we could scan without the need for the resize lock.
Comments
Runtime Triage: This is not on our current list of priorities. We will consider this feature if we receive additional customer requirements.
28-01-2020

Robbin's thoughts: Scanning the table must mean that: All items present at the start of scan and present at the end of scan have been visited once and only once. Items added during scan may or may not be visited, but only once if so. Items remove during scan may or may not be visited, but only once if so. We can't iterate the buckets. Since we can't stay inside a read-side critical section during an entire scan. (performance) Thus the number of buckets can change multiple times during a scan (grow/shrink many times). But we can iterate the hash, thus visiting all hash values. Start at hash 0, go inside critical section, check which hash range bucket 0 cover. Visit all items in bucket 0 with a hash in correct range, increase hash to end range +1. (during resize, items with hash belonging to sibling bucket can be seen, these should be ignored) Leave critical section. hash is now X+1, repeat for X+1. Hash X+1 can be in bucket 0 due to shrink we thus visit the 'new' bucket 0, but ignore all hash value below X+1. This would have the property above and be lock-free.
03-05-2019