RFR: JDK-8210187: Explicit barriers for C2

Erik Österlund erik.osterlund at oracle.com
Thu Aug 30 14:38:15 UTC 2018


Hi Roman,

Looking at these resolve barriers, I see it used in a lot of char arrays 
of strings. Are you sure you need those at all? I thought they are 
supposed to be immutable, and hence to-space invariant in the sense that 
whether you read from from-space or to-space (and hence don't chase the 
Brooks pointer), you will get equivalent values. If you do indeed not 
need them, I would prefer to remove the involved resolve barriers.

Thanks,
/Erik

On 2018-08-30 12:03, Roman Kennke wrote:
> In order to support GCs like Shenandoah, we need some explicit read- or
> write-barriers in a few places. We already introduced them in the
> runtime, interpreter and C1, this change intends to do the same for C2.
>
> It follows pretty much the same design as we did in C1.
>
> It is a bit more involved because there are *much* more intrinsics in C2
> land. Other than that it's pretty straightforward.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8210187
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8210187/webrev.00/
>
> Can I please get a review?
>
> Thanks,
> Roman
>




More information about the hotspot-gc-dev mailing list