RFR: 8302351: "assert(!JavaThread::current()->is_interp_only_mode() || !nm->method()->is_continuation_enter_intrinsic() || ContinuationEntry::is_interpreted_call(return_pc)) failed: interp_only_mode but not in enterSpecial interpreted entry" in fixup_callers_callsite

[Patricio Chilano Mateo]

On Wed, 31 May 2023 01:08:25 GMT, Dean Long <dlong at openjdk.org> wrote:

> > @dean-long I added extra asserts in all these methods just for testing and these stubs are used to resolve method handle intrinsics too, including _linkToNative which I found from tests in test/jdk/java/foreign/. For the _linkToNative case which doesn't have an interpreted version if we return the c2i adapter, since the _i2i_entry is set to the i2c adapter [1] we will actually crash in the i2c because we cannot go from c2i -> i2c. Now if this is the only such case I guess we could special case it, assuming also the carrier's path to enterSpecial will never need to resolve that method. But I'm not convinced on that approach. Otherwise the other option would be to keep the current behavior and just remove the assert added in 8288949 accepting that it's too strong, and keep this issue under the existing 8218403 bug. What do you think?
> > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/method.cpp#L1488
> 
> Sorry, are you saying we will crash in the i2c with your current patch, or only if you add extra asserts? 
>
With the current patch. If a change to interpreter only mode happens while we are resolving _linkToNative, we will return the c2i entry. That will eventually call the i2c so we will crash right away (in debug mode at least). It's just that there is no current test where that scenario will happen. As a quick test if you change resolve_static_call_C() to always return the c2i entry point to simulate the change to interpreter mode and run test/jdk/java/foreign/ you will see it.

>Which assert in 8288949 is too strong? I'm OK with not fixing 8218403 issues in this patch, but I'm not OK with it causing crashes :-)
>
The one we are hitting in fixup_callers_callsite() (subject of PR).

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

PR Comment: https://git.openjdk.org/jdk/pull/14108#issuecomment-1569367121