RFR: 8227226: Segmented array clearing for ZGC

[Per Liden]

Hi Thomas,

On 7/31/19 7:59 PM, Thomas Schatzl wrote:
> Hi,
> 
> On 31.07.19 10:19, Per Liden wrote:
>> Hi,
>>
>> I found some time to benchmark the "GC clears pages"-approach, and 
>> it's fairly clear that it's not paying off. So ditching that idea.
>>
>> However, I'm still looking for something that would not just do 
>> segmented clearing of arrays in large zpages. Letting oop arrays 
>> temporarily be typed arrays while it's being cleared could be an 
>> option. I did a prototype for that, which looks like this:
>>
>> http://cr.openjdk.java.net/~pliden/8227226/webrev.1
>>
>> There's at least one issue here, the code doing allocation sampling 
>> will see that we allocated long arrays instead of oop arrays, so the 
>> reporting there will be skewed. That can be addressed if we go down 
>> this path. The code is otherwise fairly simple and contained. Feel 
>> free to spot any issues.
> 
>    that looks like a really neat way of doing this.
> 
> Looking over this there does not seem to be any real dependency on ZGC 
> code, so if you went this way, would it be possible to provide this 
> solution for all collectors?

This is potentially dangerous for any GC doing concurrent oop_iterate(), 
as in that case the klass pointer must only be read once, with acquire 
ordering.

An example in G1 where this would break is 
HeapRegion::do_oops_on_memregion_in_humongous(), and I'm thinking there 
are more cases. For example, when a half zeroed type array in young is 
promoted to old, and then we switch the klass pointer.

I wouldn't be surprised if CMS have similar problems, but haven't check.

However, this would probably work fine for Serial and Parallel. On the 
other hand, depending on the performance impact, it's not completely 
obvious that you'd want it there.

We could perhaps add this code to the shared ObjArrayAllocator, and 
introduce a CollectedHeap::supports_segmented_array_clearing() so that 
GCs can easily opt-in when they are ready to do so.

> 
> For other collectors slightly larger segment sizes might be sufficient 
> too to slightly favor performance.
> 
> Did you measure the impact on zeroing throughput of this?

I haven't done any performance measurements of this yet. The current 4K 
segment size was just an educated guess, but it might not be the optimal 
number.

cheers,
Per