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

[Aleksey Shipilev]

On 02/22/2017 09:23 PM, Zhengyu Gu wrote:
> 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.

Yes. And it can happen even on x64 that our unlucky counter update loop would
hoist it. Let's at least keep it "volatile"?

Thanks,
-Aleksey