RFR: 8260368: [PPC64] GC interface needs enhancement to support GCs with load barriers

[Roman Kennke]

On Thu, 28 Jan 2021 22:08:17 GMT, Niklas Radomski <github.com+9200663+Quaffel at openjdk.org> wrote:

> At present, the `needs_frame` flag is used on the ppc platform to determine whether gc barriers must emit a new stack frame (and save the link register, for that matter) or not. With the introduction of load reference barriers, however, this mechansim is no longer sufficient. This holds especially true for compiler stubs as those make heavy use of volatile registers.
> 
> To mitigate this, this patch replaces the `needs_frame` flag with a simple enumeration. As the enumerators are incremental, handling the different "register preservation needs" in the actual gc barrier implementations is comparatively (pun intended) easy. 
> 
> _This is a preparational change for the ShenandoahGC port to ppc. As such, it may provide some functionality this version doesn't make use of, but that is required for the upcoming change. This way, the scope of the upcoming change is limited to GC-specific functionality; making its review a little easier._
> 
> _For the same reason, this patch also introduces patching support for `LIR_Assembler::leal`._

Thank you for doing that! I cannot really comment much on PPC specifics. Structurally and conceptually it looks reasonable to me. I've one question about the use of int vs enum though.

src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_ppc.cpp line 111:

> 109: 
> 110: void G1BarrierSetAssembler::g1_write_barrier_pre(MacroAssembler* masm, DecoratorSet decorators, Register obj, RegisterOrConstant ind_or_offs, Register pre_val,
> 111:                                                  Register tmp1, Register tmp2, unsigned int preservation_level) {

Wouldn't it make sense to use an enum type here? Or is this something that the PPC toolchain doesn't like? Applies to all occurances of similar change all over the place.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2302