RFR (XL): Backport JDK9 Shenandoah to JDK8u

[Roman Kennke]

Am Mittwoch, den 07.12.2016, 13:12 +0100 schrieb Aleksey Shipilev:
> On 12/06/2016 10:24 PM, Roman Kennke wrote:
> > This huge change backports the current state of JDK9 (minus the
> > last
> > bunch of patches) to jdk8u:
> > 
> > http://cr.openjdk.java.net/~rkennke/backport-jdk8/webrev.00/
> 
> Spot-checking:
> 
> *) src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp
> 
> These are not conditional for Shenandoah, do we hit these guarantees
> with other GCs?
> 
>   2032       guarantee(opr2->type() != T_OBJECT && opr2->type() !=
> T_ARRAY,
> "need acmp barrier?");
>   2033       guarantee(opr1->type() != T_OBJECT && opr1->type() !=
> T_ARRAY,
> "need acmp barrier?");

Nope, we don't. Should I remove them? FWIW those are the same as we
have in jdk9-shenandoah.


> *) src/share/vm/c1/c1_Runtime1.cpp
> 
> Bad indent:
> 
>   688 Handle h_obj(thread, obj);

Uh, I was reading 'bad intent' and didn't know what you mean ;-)
 Will fix it before pushing.

> 
> *) src/share/vm/memory/barrierSet.cpp
> 
> Why we moved BarrierSet::write_ref_array here? Was that the upstream
> jdk-9 move?

No, this was moved in jdk9-shenandoah because we made that method
virtual.



> *) src/share/vm/runtime/fieldDescriptor.hpp
> 
> Another leak from jdk-9?
> 
>   101   bool is_stable()                const    { return
> access_flags().is_stable(); }

No. We need it in c2 to identify stable fields. (no read-barrier
needed...)

> *) src/share/vm/runtime/os.hpp
> 
> Leak?
> 
>   56 class methodHandle;

No. It's used some lines down as methodHandle* and we're changing order
of includes and this is needed for compilation.

> *) src/share/vm/utilities/growableArray.hpp
> 
> Leak?
> 
>   30 #include "oops/oop.hpp"

No. We introduced some code that uses oopDesc::is_safe().

Ok to push after fixing the bad intent ;-)

Roman