RFR(S): ZGC: C2: Oop instance cloning causing skipped compiles

Nils Eliasson nils.eliasson at oracle.com
Tue Nov 26 10:49:48 UTC 2019


Patch 2 was not the full patch.

Use this instead:

http://cr.openjdk.java.net/~neliasso/8234520/webrev.03/

Regards,

Nils


On 2019-11-21 12:53, Nils Eliasson wrote:
> I updated this to version 2.
>
> http://cr.openjdk.java.net/~neliasso/8234520/webrev.02/
>
> I found a problen running 
> compiler/arguments/TestStressReflectiveCode.java
>
> Even though the clone was created as a oop clone, the type node type 
> returns isa_aryprt. This is caused by the src ptr not being the base 
> pointer. Until I fix that I wanted a more robust test.
>
> In this webrev I split up the is_clonebasic into is_clone_oop and 
> is_clone_array. (is_clone_oop_array is already there). Having a 
> complete set with the three clone types allows for a robust test and 
> easy verification. (The three variants end up in different paths with 
> different GCs).
>
> Regards,
>
> Nils
>
>
> On 2019-11-20 15:25, Nils Eliasson wrote:
>> Hi,
>>
>> I found a few bugs after the enabling of the clone intrinsic in ZGC.
>>
>> 1) The arraycopy clone_basic has the parameters adjusted to work as a 
>> memcopy. For an oop the src is pointing inside the oop to where we 
>> want to start copying. But when we want to do a runtime call to clone 
>> - the parameters are supposed to be the actual src oop and dst oop, 
>> and the size should be the instance size.
>>
>> For now I have made a workaround. What should be done later is using 
>> the offset in the arraycopy node to encode where the payload is, so 
>> that the base pointers are always correct. But that would require 
>> changes to the BarrierSet classes of all GCs. So I leave that for 
>> next release.
>>
>> 2) The size parameter of the TypeFunc for the runtime call has the 
>> wrong type. It was originally Long but missed the upper Half, it was 
>> fixed to INT (JDK-8233834), but that is wrong and causes the compiles 
>> to be skipped. We didn't notice that since they failed silently. That 
>> is also why we didn't notice problem #1 too.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8234520
>>
>> http://cr.openjdk.java.net/~neliasso/8234520/webrev.01/
>>
>> Please review!
>>
>> Nils
>>


More information about the hotspot-compiler-dev mailing list