RFR: JDK-8223244: Fix usage of ARRAYCOPY_DISJOINT decorator

Roman Kennke rkennke at redhat.com
Tue May 7 14:13:20 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?

Roman


More information about the hotspot-runtime-dev mailing list