RFR: JDK-8223244: Fix usage of ARRAYCOPY_DISJOINT decorator

Roman Kennke rkennke at redhat.com
Tue May 7 21:06:23 UTC 2019


>>>> Right. Added a comment there, and also checked and fixed x86_32:
>>>> http://cr.openjdk.java.net/~rkennke/JDK-8223244/webrev.02/
>>>
>>> Um. Old code:
>>>
>>>     39     if (!checkcast && !obj_int) {
>>>     40       // Save count for barrier
>>>     41       __ movptr(r11, count);
>>>     42     } else if (disjoint && obj_int) {
>>>     43       // Save dst in r11 in the disjoint case
>>>     44       __ movq(r11, dst);
>>>     45     }
>>>
>>> New code:
>>>
>>>     39     if (!checkcast) {
>>>     40       if (!obj_int) {
>>>     41         // Save count for barrier
>>>     42         __ movptr(r11, count);
>>>     43       } else if (disjoint) {
>>>     44         // Save dst in r11 in the disjoint case
>>>     45         __ movq(r11, dst);
>>>     46       }
>>>     47     }
>>>
>>> (Scribbles down truth tables). With checkcast=T, obj_int=T, disjoint=T old code saves "dst". New
>>> code does not save anything. Is that the fix for new Shenandoah code?
>>
>> With old code, checkcast and disjoint are never true at the same time. The checkcast generator
>> doesn't do that, even though the arraycopy is implicitely disjoint (why would we need checkcast
>> otherwise). We are now always asking checkcast=T && disjoint=T, and end up with the same
>> configuration as previously with checkcast=T && disjoint=F. Agree?
> 
> Agreed. Looks good then!

Thanks! Waiting on green light from jdk-submit now before pushing.

Roman




More information about the hotspot-gc-dev mailing list