RFR(XS): Heap memory usage counting not longer needs to be atomic

[Zhengyu Gu]

On 02/22/2017 03:11 PM, Aleksey Shipilev wrote:
> On 02/22/2017 09:06 PM, Roman Kennke wrote:
>> Am 22.02.2017 um 21:03 schrieb Aleksey Shipilev:
>>> On 02/22/2017 09:00 PM, Zhengyu Gu wrote:
>>>> On 02/22/2017 02:53 PM, Aleksey Shipilev wrote:
>>>>
>>>>> On 02/22/2017 08:45 PM, Zhengyu Gu wrote:
>>>>>> After guarding memory allocation with heap lock, memory usage counting also
>>>>>> under heap lock
>>>>>> or executed by VM thread during a safepoint.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~zgu/shenandoah/memory_counting/webrev.00/
>>>>> Not sure.
>>>>>
>>>>> There is ShenandoahMonitoringSupport::update_counters() that polls these outside
>>>>> safepoint. Tried with -XX:+UsePerfData -XX:+ShenandoahRegionSampling? I am
>>>>> pretty sure that some JMX/JvmStat counters would eventually do this too.
>>>> Yes, I did. There is only a read, not updates.
>>> Ok!
>>>
>>> I am uneasy about naked reads without any sort of barrier. Is there a compiler
>>> barrier at least?
>> Is there anything that prevents us from updating the counters under the
>> same lock?
> That would probably prevent allocation when sampling is enabled. Which may
> introduce performance heisenbugs we cannot observe with Visualizer? Opaque-style
> compiler barrier seems better.

What's your concern for the naked read? seeing partially updated value? which can not happen for x64.

Other than that, the value should reflect the state at the time heap lock is released.

Thanks,

-Zhengyu


>
> -Aleksey
>