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

[coleen.phillimore at oracle.com]

On 4/10/18 10:42 AM, 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!

I was going to point this out as my only comment, except you can forward 
declare Thread rather than including thread.hpp.

The rest of the change looks good to me.

thanks!
Coleen
>
>>
>> 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
>>