[urgent] RFR (XS): 8166207: Wrong use of Copy::conjoint_oops_atomic in global mark stack

[Jesper Wilhelmsson]

Looks good!
/Jesper

Den 19/9/16 kl. 17:07, skrev Thomas Schatzl:
> Hi all,
>
>   can I have reviews for this change that does not
> use Copy::conjoint_oops_atomic() to copy oops outside of the java heap
> introduced in JDK-8159422?
>
> This is because on some platforms the method is implemented and only
> ever used (apart from this one) to copy oops (oop references) *on the
> heap*.
>
> Their size may vary depending on UseCompressedOops. This crashes (or
> asserts) on 64 bit arm platforms because their implementation of this
> method directly uses this. Which means that in effect the code only
> copies half of the intended data.
> Other implementations use
>
> The suggested fix is to revert to the use of
> Copy::conjoint_memory_atomic to copy data as suggested in an early
> version of the JDK-8159422, and in a follow-up look what the intended
> meaning of this method actually is and eventually fix the methods.
>
> This will remove a lot of noise on the arm64 nightlies.
>
> Thanks go to Dean Long for finding the root problem first.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8166207
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8166207/webrev/
> Testing:
> passes jprt, waiting for rbt to pick up crashing tests with it
>
> Thanks,
>   Thomas
>