[urgent] RFR (XS): 8166207: Wrong use of Copy::conjoint_oops_atomic in global mark stack
jesper.wilhelmsson at oracle.com
Mon Sep 19 22:05:13 UTC 2016
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
> 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.
> passes jprt, waiting for rbt to pick up crashing tests with it
More information about the hotspot-gc-dev