RFR: 8287393: AArch64: Remove trampoline_call1 [v2]
Evgeny Astigeevich
duke at openjdk.org
Thu Jul 28 09:57:51 UTC 2022
On Thu, 28 Jul 2022 08:25:46 GMT, Andrew Haley <aph at openjdk.org> wrote:
>> Now I get it. Thank you.
>>
>> I agree this looks suspicious. I could not recall why I added it.
>> Debugging helped me to find out.
>> During the parsing phase of C2 compilation `ciTypeFlow::StateVector::do_invoke` causes `LinkResolver::resolve_static_call` which now has the following code:
>>
>> if (resolved_method->is_continuation_enter_intrinsic()
>> && resolved_method->from_interpreted_entry() == NULL) { // does a load_acquire
>> methodHandle mh(THREAD, resolved_method);
>> // Generate a compiled form of the enterSpecial intrinsic.
>> AdapterHandlerLibrary::create_native_wrapper(mh);
>> }
>>
>> We generate a wrapper which is `nmethod` with trampoline calls.
>> As we are in the parsing phase the output is not created.
>> I can move `Compile::current()->output() != NULL` into the preceding IF and update the comment to the following:
>>
>> Make sure this is code generation of a C2 compilation when Compile::current()->output() is not NULL.
>> C2 can generate native wrappers for the continuation enter intrinsic before code generation.
>> C1 allocates space only for trampoline stubs generated by Call LIR ops.
>
> This is all rather complicated and obscure. It seems to me that passing a bool `check_emit_size` is exactly what we should do: it's more explicit and helps the reader.
I've restored `check_emit_size` and created an assert to guard it is properly used.
I'll remove `cbuf` by fixing: https://bugs.openjdk.org/browse/JDK-8287394
-------------
PR: https://git.openjdk.org/jdk/pull/9592
More information about the hotspot-compiler-dev
mailing list