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

[Martin Doerr]

On Mon, 1 Feb 2021 19:07:22 GMT, Roman Kennke <rkennke 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`._
>
> 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.

Hi Roman,
enum type works. We only don't want to use C++11 features like enum class or typed enums because we will probably backport this change to 11u.

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

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