RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism

[David Holmes]

Hi Robin,

On 10/04/2018 10:18 PM, Robbin Ehn wrote:
> Hi all,
> 
> We have moved the global-counter to a separate change-set. The 
> global-counter
> uses a counter to determine current generation. Any reader needs to have 
> a local
> counter for which generation is currently read. By increment the 
> global-counter
> and scan for threads reading an old generation and wait for them to 
> complete, we
> know when an old generation is not visible (no pre-existing reader). In RCU
> terms, this creates a grace-period. Making this mechanism suitable for a 
> read-mostly scenario. In this initial change-set we scan JavaThreads and 
> the VMThread.

Sorry but I don't understand how this works. If a reader calls:

   31 inline void GlobalCounter::critical_section_begin(Thread *thread) {
   32   assert(thread == Thread::current(), "must be current thread");
   33   assert(thread->is_VM_thread() || thread->is_Java_thread(), "must 
be VMThread or JavaThread");
   34   assert((*thread->get_rcu_counter() & COUNTER_ACTIVE) == 0x0, 
"nestled critical sections, not supported yet");
   35   volatile uintx gbl_cnt = 
OrderAccess::load_acquire(&_global_counter._counter);
   36   OrderAccess::release_store_fence(thread->get_rcu_counter(), 
gbl_cnt + 1);
   37 }

and is preempted before the store at line 36, the writer will not see it 
and can go ahead and free the data used in the critical section. The 
reader does no validation of the counter value and so continues in to 
the critical section. Surely there has to be a handshake between the 
reader and writer, where the reader signals their intention to enter a 
critical section for generation X, then re-reads the generation count to 
check it has not changed. ??

src/hotspot/share/utilities/globalCounter.hpp

  30 // The GlobalCounter provides a synchronization mechanism threads 
which can be

The comment does not read correctly.

Thanks,
David

> A couple of enhancement to the global-counter will be looked into:
> - Quiescent state RCU semantic by using the natural state of JavaThreads 
> in the VM.
> - Asynchronous write synchronize, where reclamation, if there are 
> per-existing
> reader, is done by the last reader leaving that generation.
> - Register/deregister threads.
> 
> The current usage is the upcoming hash-table which uses the 
> global-counter to reclaim memory and to concurrently grow. We have also 
> potential use-cases in
> other work-in-progress code.
> 
> The new gtest passes on our platforms. For now you can look at the gtest 
> if you think you have a use-case for this as an example.
> 
> Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8195099
> 
> Thanks, Robbin