RFR: 8228369: Shenandoah: Refactor LRB C1 stubs

[Roman Kennke]

Hold off reviewing this, I will make some improvements to the change
today. :-)

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
>