RFR(M): 8218049: Survivor MemoryMXBean used() size granularity is region based

[sangheon.kim at oracle.com]

Hi Kim and Thomas,

On 4/4/19 11:08 AM, Kim Barrett wrote:
>> On Apr 4, 2019, at 5:02 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>
>> On Wed, 2019-04-03 at 18:43 -0400, Kim Barrett wrote:
>>> src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>>> 4589   OrderAccess::storestore();
>>>
>>> src/hotspot/share/gc/g1/g1MonitoringSupport.cpp
>>> 233   OrderAccess::loadload();
>>>
>>> […]
>>> I think these new uses of OrderAccess are an attempt to ensure the
>>> monitoring code gets a consistent pair of values.  But I don't think
>>> it accomplishes that goal.  We have
>>> […]
>>> guess there is some reason not to use a lock here? Double buffering
>>> or GlobalCounter could be used instead.
>> Double buffering (if I think it is what you think it is) would have
>> been what I would have suggested, but it seems at least some effort.
> Agreed.
>
>> For this change I suggest going back to use the subtract_until_zero()
>> method (whether we use the racy region counts or the actual "used
>> bytes" makes not difference with respect to the problem) and
>> investigate improvements in a separate CR.
> That seems like a reasonable plan.
For other reviews: Kim, Thomas and I had separate discussion mostly 
suggestions from Kim to fix the inconsistency issue but we concluded to 
revert to use subtract_until_zero().

Here's the updated webrev which includes:
1) Remove newly added barriers and use subtract_until_zero():
     I filed JDK-8221994 for further investigation.
2) Change indent at G1SurvivorRegions (from Kim)

http://cr.openjdk.java.net/~sangheki/8218049/webrev.3
http://cr.openjdk.java.net/~sangheki/8218049/webrev.3_inc/

Thanks,
Sangheon