RFR (S) 8215724: Epsilon: ArrayStoreExceptionTest.java fails; missing arraycopy check

[Erik Österlund]

Hi Aleksey,

The decision to have GCs be explicit about their choice of check-cast 
arraycopy was intentional. So I think the implementation should move 
into an epsilon barrierset inline hpp file.

The reason is that every GC seems to want their own optimized version of 
arraycopy with checkcast, handling the fact that a partial range of 
writes was committed. For the write barrier GCs (ModRef), they have 
their own partial card range dirtying mechanism, for ZGC, there is a 
load barrier per element, Shenandoah has its own interesting looking 
template thing. So the variation of arraycopy that performs checks 
covariance but does not apply any GC barriers (i.e. raw loads and 
stores), will only be used by Epsilon and would most likely be an error 
if it was used for any other GC.

Another variant could be to truly generalize the code and have a shared 
checkcast arraycopy loop that itself perform Access loads and stores, 
and let others overriding that apply whatever bulking optimizations they 
want to have. But I thought the additional template logic for that did 
not seem to be worth it, as the amount of code is so small, it seemed 
like that mechanism would introduce more complexity than it tried to 
generalize.

Do you agree?

Thanks,
/Erik

On 2019-01-07 19:19, Aleksey Shipilev wrote:
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8215724
>
> Fix:
>    http://cr.openjdk.java.net/~shade/8215724/webrev.01/
>
> As mentioned in the bug, Epsilon deliberately reuses the super-class BarrierSet, thus implicitly
> verifying it does the sane thing. This is one of those cases where super-class BarrierSet does not
> checkcast, while it should.
>
> Testing: Linux x86_64 fastdebug {new test, gc/epsilon, hotspot tier1}, jdk-submit (running)
>
> Thanks,
> -Aleksey
>