RFR: JDK-8260372: [PPC64] Add support for JDK-8210498 and JDK-8222841

[Martin Doerr]

On Fri, 5 Feb 2021 18:04:34 GMT, Niklas Radomski <github.com+9200663+Quaffel at openjdk.org> wrote:

> Introduces support for _nmethod entry barriers_ and _c2i entry barriers_ on the ppc platform. Those are required to enable concurrent class unloading for compatible garbage collectors, such as Shenandoah or zGC.
> 
> _This is a preparational change for the Shenandoah GC port to ppc. As such, it introduces features that the current version doesn't make use of, but that are required for the upcoming change. This way, the scope of the upcoming change is limited to Shenandoah-specific functionality; making its review a little easier._

Thanks for the contribution. Looks very good. I only have a few minor requests.

src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 44:

> 42: 
> 43: public:
> 44:   unsigned short get_guard_value() const {

Return type should be int.

src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 49:

> 47:   }
> 48: 
> 49:   void release_set_guard_value(unsigned short value) {

Parameter should be int.

src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp line 113:

> 111:   // Nothing to do.
> 112:   // Unlike other platforms, the frame resolution is done in the nmethod entry barrier stub.
> 113:   // This way, writing frame information on the stack can be avoided.

[optional] I'd replace the last sentence:
// PPC64 always has a valid back chain so the stub can simply pop the frame and there's nothing to do here.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3581:

> 3579: 
> 3580:     // Return to prologue if no deoptimization is required (bnelr)
> 3581:     __ bclr(Assembler::bcondCRbiIs1_bhintIsTaken, Assembler::bi0(CCR0, Assembler::equal), Assembler::bhintIsTaken);

Branch hint is provided twice. Not an error, but bcondCRbiIs1 would be cleaner if you keep it at the end.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3592:

> 3590: 
> 3591:     // Restore link register. Points to an instruction in the previous Java frame; effectively resuming
> 3592:     // its execution after this method's deoptimization.  This method's prologue is aborted.

Unprecise: We're not resuming in the caller after deoptimization, we call handle_wrong_method which finds a better callee (e.g. interpreter) and jumps to it.

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

Changes requested by mdoerr (Reviewer).

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