RFR(M): 8232896: ZGC: Enable C2 clone intrinsic

Per Liden per.liden at oracle.com
Mon Nov 4 09:26:14 UTC 2019


Hi Nils,

On 11/4/19 10:16 AM, Nils Eliasson wrote:
> 
> On 2019-11-01 12:50, Per Liden wrote:
>> Hi Nils,
>>
>> On 10/31/19 5:37 PM, Nils Eliasson wrote:
>>> Hi,
>>>
>>> This patch fixes and enables the clone intrinsic for C2 with ZGC.
>>>
>>> The main thing added is an implementation of the 
>>> ZBarrierSetC2::clone_at_expansion method. This method handles clone 
>>> expansion for regular objects and primitive arrays that hasn't 
>>> already been reduced by optimizations. (Oop array clones doesn't go 
>>> through this path.)
>>>
>>> The code switches on the type of the source to either make a leaf 
>>> call to a runtime clone for regular objects, or delegate to 
>>> BarrierSetC2::clone_at_expansion for primitive arrays.
>>>
>>> Updated micro benchmark shows great gains, especially for small 
>>> objects that now will be reduced to inlined move-store sequences.
>>
>> Sweet! The speedup of micro:Clone is impressive!
>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232896
>>>
>>> Webrev: http://cr.openjdk.java.net/~neliasso/8232896/webrev.02/
>>
>> My review comments summarized in a patch on top of yours. Let me know 
>> if there's something you don't agree with. The changes are:
>> * Changed the type of the runtime function's size arguments from 
>> TypeInt::INT to TypeLong::LONG, to make it 64 bits, rather than 32.
>> * Changed the new runtime function to call HeapAccess::clone() rather 
>> than ZBarrier::clone_oop(), since ZBarrier is the backend for the 
>> access layer, not the frontend.
>> * Renamed clone_oop() to clone(), as we're cloning an object rather 
>> than an oop.
> 
> Overall, I like your suggestions.
> 
> One problem with using "clone" is that is suggest that it will create a 
> new Object too (like how java.lang.Object.clone does). But this function 
> only copies the contents. I am open to suggestions, and even keeping the 
> clone name, but feel a slight bit of unease.

I see your points. However, I see two reasons to keep that name:
1) In the Access API it's called Access::clone(src, dst, size), and 
since ZBarrierRuntime::clone() is a bridge to that function it might be 
good to use the same name.
2) The clone() function has a dst argument, implying that dst already 
exists.

Objections?

cheers,
Per

> 
> Thanks!
> 
> /Nils
> 
>> * Added const where applicable.
>> * Adjusted an include line.
>> * Moved the clone_at_expansion() function up in the file.
>>
>> http://cr.openjdk.java.net/~pliden/8232896/webrev.pliden_review.0
>>
>> I ran micro:Clone to verify my changes.
>>
>> cheers,
>> Per
>>
>>>
>>>
>>> Please review,
>>>
>>> Nils Eliasson
>>>


More information about the hotspot-compiler-dev mailing list