RFR: 8228369: Shenandoah: Refactor LRB C1 stubs

[Roman Kennke]

Please review this updated patch:

http://cr.openjdk.java.net/~rkennke/JDK-8228369/webrev.01/

It moves the cset-check and forwarded-check out of the runtime-stub, and
one level up into the code-stub. This has the advantage that we can
utilize the C1 reg-alloc to get tmp-regs and not need to mess with
shuffling registers. It also avoids building the call-frame unless we
really need to. It also does some short-cuts when not in cset or when
forwarded, branching directly to the continuation rather than to some
label (and then to the continuation).

The runtime call stub now really only does the runtime call.

What do you think?

Roman


>  Currently, interpreter and C1 are calling through a shared stub. This
> is somewhat rigid, and not really the C1-ish way to do it. In
> particular, it makes it very difficult to pass an additional argument to
> the runtime-call, which we're going to need for self-fixing-LRBs.
> 
> This patch makes the C1 path go through its own stub that is now
> generated in the same way as other C1 runtime stubs. Notable changes:
> 
> - the save_vector_registers()/restore_vector_registers() is no longer
> needed and we can instead re-use the similar methods from StubAssembler.
> This is also more useful maintenance-wise if the calling
> convention/registers ever change, if bugs come up in that code, etc.
> - The null-check in the CodeStub branches directly to the continuation
> instead of skipping the call.
> - Register allocation for the result forces rax/r0 (the return
> register), which means we can avoid some shuffling in the CodeStub.
> - Calling the runtime-stub now allows to pass parameters, which will be
> *very* helpful when we want to the sfx-lrbs.
> - In order to make the interpreter stub and the C1 stub share as much
> code as possible, I extracted gen_cset_check() and gen_resolved_check()
> to be used by both. We could in-fact consider to do away with the
> interpreter stub altogether, inline the whole code, and benefit from the
> passed-in tmp register, but I took the approach to not touch that code
> unless needed: it's quite a nightmare to get the register shuffling
> right with the interpreter (even more so than C1).
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8228369
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8228369/webrev.00/
> 
> Testing: hotspot_gc_shenandoah (x86_64, aarch64)
> 
> Good?
> 
> Roman
>