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

Dean Long dlong at openjdk.org
Tue Aug 23 19:10:30 UTC 2022


On Tue, 23 Aug 2022 06:53:36 GMT, Dean Long <dlong at openjdk.org> wrote:

> generate_Continuation_doYield_entry() creates an interpreter entry point, but jumps to a compiled stub, which needs to be walkable.  The interpreter entry does not create an interpreter frame, so frame walking expects a compiled frame.  Normally everything is OK, but if C1 does not inline the intrinsic and we get to the interpreter entry through the c2i adapter, then things can break if the c2i adapter padded the stack because of alignment.  The easiest fix is to undo what the c2i adapter might have done.

This intrinsic is new with Loom.  Stack walking can deal with stack adjustments, but only if there is an interpreter frame to do the fixup.  The problem here is that generate_Continuation_doYield_entry() code is registered as an interpreter entry point, but it does not create an interpreter frame to fixup adapter adjustments.  Normally everything is fine because the interpreter entry point is only called by interpreted code, so there is no adjustment.  But with C1 and inlining turned off, the intrinsic does not get inlined, so we end up going through a c2i adapter.

Fixing JDK-8292694 would hide the problem.  Another option would be to create a real interpreter frame.  I also listed a few other options in the JBS issue:

 - force C1 to always inline this intrinsic.
 - print a warning and refuse to enable Continuations if the doYield intrinsic is disabled
 - make doYield a special native intrinsic like enterSpecial, bypassing inlining checks

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

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


More information about the hotspot-compiler-dev mailing list