The standard Java virtual machine is a stack-based Java byte-code execution engine with well-defined execution semantics [11]. In this standard execution model, which we refer to as actual time execution, the passing of time is not dependent on the progress of the application. In other words, the system clock advances regardless of how many byte-code instructions are processed. Also, the program can advance at a variable rate, since it depends not only on processor speed, but also on other unpredictable things, such as interrupts and application inputs. Moreover, the JVM certainly does not make strong guarantees regarding timely program progress: it may decide, for example, to perform garbage collection at any point.
To solve such problems, much research has been devoted to executing applications in real time or with more predictable performance models, wherein the runtime can guarantee that instructions or sets of instructions will meet given deadlines. Thus, the rate of an application's progress is made dependent on the passing of time.
In JiST, the opposite is true: that is, the progress of time depends on the progress of the application. The application clock, which represents simulation time, does not advance to the next discrete time point until all processing for the current, discrete simulation time has been completed.
In simulation time execution, individual primitive application byte-code
instructions are processed sequentially, following the standard Java control
flow semantics, but the application time remains unchanged. Application code
can advance time only via the sleep(
) system call. In essence,
every instruction takes zero time to process except sleep, which
advances the simulation clock forward by exactly simulated time quanta.
The JiST runtime processes an application in its simulation-temporal order
until all the events are exhausted or until a pre-determined ending time is
reached, whichever comes first. We summarize these different execution models
in Table 2.