RFR: System.gc() with ExplicitGCInvokesConcurrent should block

[Aleksey Shipilev]

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.

-Aleksey