RFR: 8292584: assert(cb != __null) failed: must be with -XX:-Inline

[Dean Long]

On Tue, 23 Aug 2022 19:21:17 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Is it hard to create a real interpreter frame? We should avoid "special case" which may cause more issues later.

It's not too hard, but there may be places in Loom that assume it is compiled.


 >>   force C1 to always inline this intrinsic.

> No. Disabling inlining is legal.

> What C2 does if inlining is disabled?

This is what C2 does.  It always inlines intrinsics even if inlining is disabled.  Making C1 do the same would fix the problem, but it is a change in behavior.

>>     make doYield a special native intrinsic like enterSpecial, bypassing inlining checks

> Is it easier to implement vs real interpreter frame?

I believe it is slightly easier, using multiple entry points like enterSpecial, and has the advantage of not increasing stack size.  But I wonder if there was a reason why one is native and the other is not:


307      @IntrinsicCandidate
308      private static int doYield() { throw new Error("Intrinsic not installed"); }
309  
310      @IntrinsicCandidate
311      private native static void enterSpecial(Continuation c, boolean isContinue, boolean isVirtualThread);
312  


I forgot to mention that aarch64 is in the same situation.  If the aarch64 adapter added stack space, then I would expect it to hit the same assert.  So it would be consistent with aarch64 for x86_64 to require no adapter adjustment (JDK-8292694
), and I could add #ifdef ASSERT logic to check that.

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

PR: https://git.openjdk.org/jdk/pull/9974