gov.nasa.jpf.jvm.bytecode

Class DIRECTCALLRETURN

java.lang.Object

gov.nasa.jpf.vm.Instruction

gov.nasa.jpf.vm.bytecode.ReturnInstruction

gov.nasa.jpf.jvm.bytecode.DIRECTCALLRETURN

All Implemented Interfaces:

JVMInstruction, Attributable, InstructionInterface, java.lang.Cloneable

public class DIRECTCALLRETURN
extends ReturnInstruction
implements JVMInstruction

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

Modifier and Type	Method and Description
void	accept(JVMInstructionVisitor 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, asInstruction, 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, isMonitorEnterPrologue, isSchedulingRelevant, removeAttr, replaceAttr, requiresClinitExecution, setAttr, setContext, setLocation, setMethodInfo, toPostExecString, toString, typeSafeClone

Methods inherited from class java.lang.Object

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

Methods inherited from interface gov.nasa.jpf.vm.bytecode.InstructionInterface

asInstruction, getFileLocation, getFilePos, getInstructionIndex, getLength, getLineNumber, getMethodInfo, getMnemonic, getNext, getNext, getPosition, getPrev, getSourceLine, getSourceLocation, isBackJump, isCompleted, isFirstInstruction, toPostExecString

Methods inherited from interface gov.nasa.jpf.util.Attributable

addAttr, attrIterator, attrIterator, getAttr, getAttr, getNextAttr, hasAttr, hasAttr, removeAttr, replaceAttr, setAttr

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?

Specified by:

isExtendedInstruction in interface InstructionInterface

Overrides:

isExtendedInstruction in class Instruction

getByteCode

public int getByteCode()

Specified by:

getByteCode in interface InstructionInterface

accept

public void accept(JVMInstructionVisitor insVisitor)

Specified by:

accept in interface JVMInstruction

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 interface InstructionInterface

Specified by:

execute in class Instruction