Notes

Simulators >> JiST (Examples/Approaches)
============================

Approach to Simulation TIme in Discrete event simulaton (JiST simulator):
===============================================
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.
actual time - program progress and time are independent
real time - program progress depends on time
simulation time - time depends on program progress
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($ n$) system call. In essence, every instruction takes zero time to process except sleep, which advances the simulation clock forward by exactly $ n$ 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

Object Model & Execution Semantics
================================
To enforce strict partitioning of a simulation into entities and to prevent object communication across entity boundaries, each (mutable/state) object in the system must belong to a single entity and must be entirely encapsulated within it. In Java, this merely means that all references to an object must originate either directly or indirectly from a single entity.

The JiST kernel manages a simulation at the granularity of its entities. Instructions and method invocations within an entity follow the regular Java control flow and semantics, entirely opaque to the JiST infrastructure. The vast majority of this code is involved with encoding the logic of the simulation model and is entirely unrelated to the notion of simulation time

In contrast, invocations on entities (as opposed to regular objects) represent simulation events. The execution semantics are that method invocations on entities are non-blocking. They are merely queued at their point of invocation, not invoked. The invocation is actually performed on the target entity only when it reaches the same simulation time as the calling (or source) entity. In other words, cross-entity method invocations act as synchronization points in simulation time.
Or, from a language-oriented perspective, an entity method is like a coroutine, albeit scheduled in simulation time. This is a convenient abstraction in that it eliminates the need for an explicit simulation event queue. It is the JiST kernel that actually runs the event loop, which processes the simulation events, invoking the appropriate method for each event dequeued in its simulation time order and executing the event to completion without continuation.
We reintroduce the separation of entities at runtime, by transparently replacing all entity references within the simulation bytecode with special objects, called separators, as shown on the right of Figure 4. The separator object identifies a particular entity, but without referencing it directly. Rather, separators store a unique entity identifier that is generated by the kernel for each entity during its initialization. Separators can be held in local variables, stored in fields or objects or passed as method parameters, just like the regular object references that they replace. Since the replacement occurs across the entire simulation bytecode, it remains type-safe.
Due to this imposed separation, we guarantee that interactions among entities can only occur via the JiST kernel. Furthermore, since entities do not share any application state, each entity may actually progress through simulation time independently between interactions. The separators, in effect, represent an application state-time boundary around each entity
Thus, by tracking the simulation time of each individual entity, these separators allow for concurrent execution.
By adding the ability to checkpoint entities, via Java serialization, for example, the system can support speculative execution as well.
Finally, separators also provide a convenient point for the distribution of entities across multiple machines.
In a distributed simulation, the separators function also as remote stubs and transparently maintain a convenient abstraction of a single system image.
Separators transparently store and track the location of entities as they migrate among machines in response to fluctuating processor, memory and network loads.
>>>>>> Entity/Separators in JiST can be very well be encapsulated as Akka Actors <<<<<<<<<<<<<<<<<<
>>>>>> Think about Simulation Time Clock Implementation <<<<<<<<<<<<<<<<<
>>>>>>> Can Simulation Event Q be ring buffer <<<<<<<<<<<<<<<<<<<<<<<<<<
The role of the simulation developer, then, is to codify the simulation model in regular Java and to partition the state of the simulation not only into objects, but also into a set of independent entities along reasonable application boundaries. The JiST infrastructure will transparently execute the program efficiently, while retaining the simulation time semantics.

there may be multiple threads that share the simulation event queue and execute the events in parallel. The JiST kernel, however, does guarantee that events are atomic. Thus, events on the same entity are executed to completion without interruption. Entity invocations do not interrupt event processing; the invocation is merely enqueued. Also, other events may not interrupt processing, even during a sleep call.
The sleep merely advances the local simulation clock. For instance, take two events t_1 and t_2, at times t=1 and t=2, respectively. Assume that the first event, during the course of its execution, calls sleep for 3 time quanta. Nevertheless, t_2 will be invoked only after t_1 processing is complete. In effect, the sleep call is used for scheduling outgoing invocations with delay, but not for delaying internal operations. Thus, all operations on the state of an entity occur atomically, at the simulation time of the current event.

Non-public methods are considered to be regular object methods, not entity methods, and have the regular Java invocation semantics. Furthermore, since entity method invocations are event-based, they are performed without continuation. Consequently, there can be no continuation defined. In other words, public entity methods must return void and can not statically declare any throwable exceptions. If, at runtime, an exception nevertheless occurs and escapes outside the boundary of an entity to the kernel event loop, then the system will immediately terminate the faulty simulation.
>>>>>Think more about exception handling in Simulations<<<<
The simulation time invocations are introduced by the rewriter, which inspects all method invocation instructions to find invocations on targets that are entities. At this program location, the stack will contain the target reference (in fact, the separator object) and any arguments. The rewriter inserts bytecode instructions to pack the arguments into an object array and to rearrange the stack to hold three items: the target, a method reflection object and the invocation argument array. The invocation instruction is then converted into a call to the simulation kernel, which creates and schedules a simulation event with this information. For performance, method reflection objects are pre-generated statically, object arrays are pooled to avoid object instantiation as are the event objects, the expensive Java reflection access checks are performed once and then safely disabled and synchronization locks are escalated wherever possible. Unfortunately, the Java type system and reflection interface forces us to wrap primitive types in their object counterparts to be placed in the argument array, which incurs a small, but notable overhead.It would be nice to have the JVM extended to support the efficient ``boxing'' of primitive types.

Timeless Objects
===============
The notion of timeless objects, introduced purely for reasons of performance. A timeless object is defined as one that will not change over time. Knowing that a value is temporally stable, allows the system to safely pass it across entities by reference, rather than by copy. Marker interface is used to indicate to the kernel or the rewriter/compiler to not worry about passing by copy but can freely pass by reference.
The timeless tag may also be useful for sharing state among entities in an effort to reduce simulation memory consumption, as depicted in Figure 5. This facility should be exercised with care. Since entities may progress at different rates through simulation time, any shared state must actually be timeless. Objects with temporally unstable values shared across entities will create temporal inconsistencies in the state of the simulation.

Scripting & Reflection
=====================
JiST can easily provide multiple scripting interfaces to configure its simulations without source modification, memory overhead, or loss of performance. (1) As before, the simulation classes are loaded and rewritten on demand. (2) The script engine configures the simulation, using reflection and may even dynamically compile the script to bytecode for performance. (3) The simulation then runs, as before, interacting with the kernel as necessary.

Continuations in Simulation
=========================
It remains cumbersome to model simulation processes, since they must be written as event-driven state machines. While many entities, such as network protocols or routing algorithms, naturally take this event-oriented form, other kinds of entities do not. For example, an entity that models a file-transfer is more readily encoded as a process than as a sequence of events.
In order to invoke an entity method with continuation, the simulation developer merely needs to declare that a given entity method is blocking. Syntactically, an entity method is blocking if and only if it declares that it throws a JistAPI.Continuation exception. This exception is not actually thrown. It acts merely as a method tag and as an indication to the JiST rewriter. Moreover, it need not be explicitly declared further up the call-chain, since it is a sub-class of Error, the root of an implicit exception hierarchy.
The addition of blocking methods allows simulation developers to regain the simplicity of process-oriented development. When a blocking entity method is invoked, the continuation state of the current event is saved and attached to a call event. When this call event is complete, we schedule a callback event to the caller. The continuation is restored and the caller continues its processing, albeit at a later simulation time.
Unlike process-oriented simulation runtime, which must allocate a fixed stack-space for each real or logical process, the JiST stack space is unified across all its active entities, reducing memory consumption. The continuation stacks actually exist in the heap along with the events that contain them and any objects that they reference. Moreover, our model is actually closer to threading, in that multiple continuations can exist simultaneously for a single entity. Finally, there is no system context switching required. The parallelism occurs only in simulation time, so the underlying events may be executed sequentially within a single thread of control.
>>>>>>>>>> Can software transaction memory ie Agents help here - akka & clojure <<<<<<<<
Unfortunately, saving and restoring the call-stack for the purposes of continuation is not a trivial task in Java [20]. The fundamental difficulty arises from the fact that stack manipulations are not supported at either the language, library or bytecode level.
Our implementation of continuations draws on ideas in the JavaGoX [21] and PicoThreads [3] projects, which also need to save the stack, albeit in a radically different context. We introduce an important new idea to these approaches, which eliminates the need to modify method signatures. This fact is significant, since it allows our implementation to function even across the standard Java libraries. This design also eliminates the use of exceptions to carry state information and is considerably more efficient for our simulation needs.

Since we are not allowed access to the call-stack in Java, we instead convert parts of the original simulation program into a continuation-passing style (CPS).
. For this purpose, the JiST rewriter incrementally produces a call-graph of the simulation at runtime as it is loaded and uses the blocking method tags to compute all continuable methods. Continuable methods are those methods that could exist on a call stack at the point of a blocking entity method invocation. Or, more precisely, a continuable method is defined recursively as any method that contains:
an entity method invocation instruction, whose target is a blocking method; or
a regular object method invocation instruction, whose target is a continuable method.
Finally, the kernel functions as the continuation trampoline, as shown in Figure 13. When the kernel receives a request to perform a call with continuation, it registers the call information, switches to save mode and returns to the caller. The stack then unwinds and eventually returns to the event loop, at which point the call event is dispatched with the continuation attached. When the call event is received, it is processed, and a callback event is dispatched in return with both the continuation and the result attached. Upon receiving this callback event, the kernel switches to restore mode and invokes the appropriate method. The stack then winds up to its prior state and the kernel receives a request for a continuation call yet again. This time, the kernel simply returns the result of the call event and allows the event processing to continue from where it left off.
The performance of a blocking call with a short stack is only around 2-3 times slower than two regular events. Thus, continuations present a viable, efficient way to reclaim process-oriented simulation functionality within an event-oriented simulation framework.

Using continuations, we also can recreate various concurrency primitives in simulation time. As an example, we construct the Channel primitive from Hoare's Communicating Sequential Processes (CSP) language [9]. Other primitives, such as threads, locks, semaphores, barriers, monitors, FIFOs, etc., can readily be built either atop Channels, or directly within the kernel.