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

[Erik Österlund]

Hi Robbin,

Looks good.

Thanks,
/Erik

On 2018-04-10 16:42, Robbin Ehn wrote:
> Hi Erik,
>
> On 04/10/2018 02:45 PM, Erik Österlund wrote:
>> Hi Robbin,
>>
>> The local counter loaded in critical_section_begin/end should not be 
>> volatile (the compiler will produce unnecessarily crappy code).
>
> Thanks, fixed!
>
>>
>> globalCounter.hpp lacks a few includes:
>> memory/allocation.hpp and memory/padded.hpp.
>
> Thanks, fixed!
>
>>
>> Otherwise it looks good to me. I note that the lack of 
>> release_store_fence() in critical_section_end() means that stores and 
>> loads can float up into the critical section. I'm assuming that is 
>> fine in the envisioned use cases, as long as accesses do not float 
>> out from the critical section.
>
> Yes, you are correct, added a comment.
>
> Full: http://cr.openjdk.java.net/~rehn/8195099/v2/webrev/
> Inc : http://cr.openjdk.java.net/~rehn/8195099/v2/inc/webrev/
>
> Thanks, Robbin
>
>>
>> Thanks,
>> /Erik
>>
>> On 2018-04-10 14:18, 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.
>>>
>>> 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
>>