RFR: System.gc() with ExplicitGCInvokesConcurrent should block

[Zhengyu Gu]

On 09/06/2017 12:06 PM, Aleksey Shipilev wrote:
> On 09/06/2017 06:03 PM, Zhengyu Gu wrote:
>> On 09/06/2017 11:58 AM, Aleksey Shipilev wrote:
>>> On 09/06/2017 05:56 PM, Zhengyu Gu wrote:
>>>> On 09/06/2017 11:20 AM, Aleksey Shipilev wrote:
>>>>> Current ExplicitGCInvokesConcurrent violates the System.gc() contract in this part: "***When
>>>>> control
>>>>> returns from the method call,*** the Java Virtual Machine has made a best effort to reclaim space
>>>>> from all discarded objects.". To fix it, we need to wait for the end of cycle before returning from
>>>>> System.gc() call:
>>>>>      http://cr.openjdk.java.net/~shade/shenandoah/concthread-eic-block/webrev.01/
>>>>
>>>> Does it make sense to move flag setting inside mutex lock? it provides release-unlock semantics.
>>>
>>> Nope, because the is_conc_gc_requested() is lock-free.
>>
>> Yes, but an acquire in is_conc_gc_requested should be sufficient, no?
> 
> Memory model wise, you need to match acquires and releases. So if you release under the lock, you
> better be user to acquire under it too. Which makes is_conc_gc_requested locked. It is cleaner to
> separate OrderAccess for acq-rel semantics and mutex for mutual exclusion here.

Then, okay.

-Zhengyu

> 
> -Aleksey
>