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

[Thomas Schatzl]

Hi,

On Mon, 2016-09-19 at 17:07 +0200, Thomas Schatzl wrote:
> 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 

  ... overloading, not the flag, to accidentally (I think) get the
correct behavior.

> 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

Still did not start. I am however very confident that this is the
correct fix.

Thanks,
  Thomas