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

[Dean Long]

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.

What we have is:

   compiled frame --> c2i --> generate_Continuation_doYield_entry --> cont_doYield (compiled frame)
   interpreted frame --> generate_Continuation_doYield_entry --> cont_doYield (compiled frame)

Where only the endpoints have frames.  The c2i adapter and the generate_Continuation_doYield_entry are frameless, so generate_Continuation_doYield_entry looks like an adapter.  But what kind of adapter?  If it is called by an interpreter frame, then we need an i2c adapter (nop in this case), but if it is called by a compiled frame through a c2i adapter, then we need an "anti-c2i" adapter to undo the c2i, resulting in "c2c".  

I see why enterSpecial is not a problem.  It has a compiled native nmethod, so the Method's _from_compiled_entry field points directly to the compiled entry point.  We could do the same for doYield, and set _from_compiled_entry to point to the StubRoutines::cont_doYield() entry point, but out code doesn't support having a _from_compiled_entry point that is not inside an nmethod.

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

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