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

[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