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