The different stubs, what they are for..

[Peter Helfer-2]

I'm trying to compile a small overview about the interpreter, and how it works all together. I stumbled across some Stubs I don't know yet the precise meaning or intention behind, could somebody correct my assumptions ?

- early_ret(TosState) //  forced return by debugger/JVMTI, removes activation frame, puts assignment compatible result on stack ?
- slow signature handler // what is that for ?
- continuation handler(TosState) // it sets interpreter mode (by setting last_sp = NULL_WORD), and continues dispatching


Thanks, Peter

[steve.goldman]

Peter Helfer wrote:
> I'm trying to compile a small overview about the interpreter, and how it
> works all together. I stumbled across some Stubs I don't know yet the
> precise meaning or intention behind, could somebody correct my assumptions ?
>
> - early_ret(TosState) //  forced return by debugger/JVMTI, removes
> activation frame, puts assignment compatible result on stack ?

jvmti can ask the jvm to abort the current activation as if it were
complete and return a result of the type expected.

> - slow signature handler // what is that for ?

Passing native arguments is done by signature handlers that are separate
little pieces of code for particular signatures. For signatures that are
too wide (many parameters) there is a generic handler to copy the args
from the location that Java put them to where the native call expects
them. You could in theory run with only the slow signature handler. It
is slow since it is a jvm entry and a safepoint could occur. The latter
point has caused some bugs in the past because the youngest frame is at
an interesting state.

> - continuation handler(TosState) // it sets interpreter mode (by setting
> last_sp = NULL_WORD), and continues dispatching

This is used as part of deoptimization. When we create an interpreter
frame(s) to replace a compiled frame we need to come up with pc's to
return to. Depending on the exact state we were in when the deopt
happened we made need various spots in the interpreter to resume
execution. This is one of those. Look at the code in
vframeArrayElement::unpack_on_stack().

--
Steve