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