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