RFR: 8286897: Loom: Cleanup x86_64 StubGenerator

[Ron Pressler]

On Tue, 17 May 2022 16:39:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. 
> 
> There should be no behavior changes. The changes themselves should speak for themselves, but here is a brief list:
>  - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code
>  - `_masm` and `masm` shadowing can just use whatever is currently defined as `__`
>  - more strong cohesion between `post_call_nop`, its associated PC and its oopmap
>  - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway;
>  - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches;
>  - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do;
>  - inline comments are reflowed to block-like comments, matching the usual style of stub code;
>  - labels are prefixed with `L_` for clarity (used in some places in Hotspot);
>  - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight;
>  - `continuation_*` are documented a bit better;
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual`
>  - [x] Linux x86_64 fastdebug, `serviceability/jvmti`
>  - [x] Linux x86_64 fastdebug, `runtime/vthread`

The changes looks fine, but why do you want to remove assert_asm? It's useful even though it's new and not applied to old code. But if there's a good reason to do so, then it should also be removed from the aarch64 port.

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

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