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

Aleksey Shipilev shade at redhat.com
Wed Feb 22 20:11:59 UTC 2017


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.

-Aleksey



More information about the shenandoah-dev mailing list