[urgent] RFR (XS): 8166207: Wrong use of Copy::conjoint_oops_atomic in global mark stack
thomas.schatzl at oracle.com
Mon Sep 19 15:13:13 UTC 2016
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
> 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
> 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
> 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.
> 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
More information about the hotspot-gc-dev