gov.nasa.jpf.jvm.bytecode

Class DIRECTCALLRETURN

java.lang.Object

gov.nasa.jpf.vm.Instruction

gov.nasa.jpf.jvm.JVMInstruction

gov.nasa.jpf.jvm.bytecode.DIRECTCALLRETURN

All Implemented Interfaces:

InstructionVisitorAcceptor, ReturnInstruction, Cloneable

public class DIRECTCALLRETURN
extends JVMInstruction
implements ReturnInstruction

this is used to return from a DirectCallStackFrame Note that it is NOT a ReturnInstruction, in case listeners monitor these and expect corresponding InvokeInstructions. Although this would seem intuitive, it would be pointless to derive because the ReturnInstruction.enter() does a lot of things we would have to cut off, i.e. it would require more effort to undo this (no sync, no return value, no pc advance on the returned-to stackframe etc.) However, having a dedicated direct call return instruction makes sense so that the ReturnInstruction of the called method does not have to handle direct calls specifically

Field Summary

Fields

Modifier and Type	Field and Description
static int	OPCODE

Fields inherited from class gov.nasa.jpf.vm.Instruction

attr, insnIndex, mi, position

Constructor Summary

Constructors

Constructor and Description
DIRECTCALLRETURN()

Method Summary

Methods

Modifier and Type	Method and Description
void	accept(InstructionVisitor insVisitor)
Instruction	execute(ThreadInfo ti) this is the real workhorse returns next instruction to enter in this thread <2do> it's unfortunate we roll every side effect into this method, because it diminishes the value of the 'executeInstruction' notification: all insns that require some sort of late binding (InvokeVirtual, GetField, ..) are not yet fully analyzable (e.g.
int	getByteCode()
boolean	isExtendedInstruction() is this one of our own, artificial insns?

Methods inherited from class gov.nasa.jpf.vm.Instruction

addAttr, attrIterator, attrIterator, cleanupTransients, getAttr, getAttr, getFileLocation, getFilePos, getInstructionIndex, getLength, getLineNumber, getMethodInfo, getMnemonic, getNext, getNext, getNextAttr, getPosition, getPrev, getSourceLine, getSourceLocation, getSourceOrLocation, hasAttr, hasAttr, init, isBackJump, isCompleted, isFirstInstruction, isSchedulingRelevant, removeAttr, replaceAttr, requiresClinitExecution, setAttr, setContext, setLocation, setMethodInfo, toString, typeSafeClone

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Field Detail

OPCODE

public static final int OPCODE

See Also:

Constant Field Values

Constructor Detail

DIRECTCALLRETURN

public DIRECTCALLRETURN()

Method Detail

isExtendedInstruction

public boolean isExtendedInstruction()

Description copied from class: Instruction

is this one of our own, artificial insns?

Overrides:

isExtendedInstruction in class Instruction

getByteCode

public int getByteCode()

Specified by:

getByteCode in class Instruction

accept

public void accept(InstructionVisitor insVisitor)

Specified by:

accept in interface InstructionVisitorAcceptor

execute

public Instruction execute(ThreadInfo ti)

Description copied from class: Instruction

this is the real workhorse returns next instruction to enter in this thread <2do> it's unfortunate we roll every side effect into this method, because it diminishes the value of the 'executeInstruction' notification: all insns that require some sort of late binding (InvokeVirtual, GetField, ..) are not yet fully analyzable (e.g. the callee of InvokeVirtuals is not known yet), putting the burden of duplicating the related code of enter() in the listener. It would be better if we factor this 'prepareExecution' out of enter()

Specified by:

execute in class Instruction