RFR: Access barriers for arraycopy

Roman Kennke rkennke at redhat.com
Tue Feb 20 18:01:32 UTC 2018


Hi Aleksey,

On Tue, Feb 20, 2018 at 5:54 PM, Aleksey Shipilev <shade at redhat.com> wrote:
> On 02/20/2018 05:38 PM, Roman Kennke wrote:
>> This adds support for arraycopy barriers using the new Access API.
>> - Add the hooks in a bunch of places where arraycopy is used
>> - Fix a small issue in the actual Access API
>> - Make Shenandoah Access barriers apply read- and write-barriers to
>> the src and dst objects, and re-resolve the actual addresses using
>> some pointer math.
>>
>> This should reduce upstream exposure even more.
>>
>> I'll upstream the changes required to shared code ASAP.
>>
>> Test: hotspot_gc_shenandoah
>>
>> http://cr.openjdk.java.net/~rkennke/arraycopy-access-barriers/webrev.00/
>
> *) Since we are stabilizing sh/jdk*10*, I would prefer not to extend Access API here: when doing
> this, we are risking unforeseen interactions with the rest of VM and other GCs. Do we actually need
> the extensions to work correctly?

If we don't want that in 10, they we should get the shenandoah/jdk
into shape ASAP, because this is work that's important to get
Shenandoah in shape for upstreaming ;-)

It's not an extension of the Access API per se. It#s more like a bug
fix. There's a call to Raw::arraycopy() that plain simply wrong: that
call does not accept oop arguments. Since it was never used in
upstream yet, the compiler never resolved and complains about that. I
would like to get it into Shenandoah first to give it some exposure
and testing, then bring it upstream as soon as possible. No, it
doesn't not work/make sense without those shared code changes.

> *) Stray whitespace before "((T*)":
>
>   87     src =  ((T*) (void*) src_obj) + src_offset;
>
>  103     src =  ((T*) (void*) src_obj) + src_offset;

Fixed.
http://cr.openjdk.java.net/~rkennke/arraycopy-access-barriers/webrev.01/

Ok now? Or better wait for shenandoah/jdk ? (I have a local copy of
shenandoah/jdk basically ready to go, basically what is in
shenandoah/jdk now (clone of shenandoah/jdk10 from a few days ago,
plus merges from latest shenandoah/jdk10 and jdk/jdk ).

Roman


More information about the shenandoah-dev mailing list