RFR: 8287393: AArch64: Remove trampoline_call1 [v2]
Evgeny Astigeevich
duke at openjdk.org
Wed Jul 27 10:58:02 UTC 2022
On Tue, 26 Jul 2022 14:44:01 GMT, Andrew Haley <aph at openjdk.org> wrote:
>> Hi @theRealAph,
>> I am sorry I did not get your comment. Could you please explain it?
>>
>> Thanks,
>> Evgeny
>
> The addition is
> 'PhaseOutput* phase_output = Compile::current()->output();'
> then
> 'phase_output != NULL && phase_output->in_scratch_emit_size()'
>
> so AFAICS `Compile::current()->output()` is now checked for null, where it was not before.
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.
-------------
PR: https://git.openjdk.org/jdk/pull/9592
More information about the hotspot-compiler-dev
mailing list