Skip to content

Changing Space and Time in Software Execution – The Future is Simulated

Last week during my JavaOne talk titled “One JVM To Monitor Them All” I proposed a new approach to distributed/parallel computation based on the replication of software execution behavior across one or more processing units in which the simulated played back behavior is augmented with extended software execution behavior.

Execute once. Simulate anywhere. Augment anytime.

Instead of forking asynchronous tasks at particular points in the execution of code, the same thread call stack execution behavior (but not actual class byte code) is replicated to multiple simulating machines in which the asynchronous task, such as a cross cutting concern like auditing, is executed like it was within the same thread execution context (of the simulation). This allows us to program such extensions in a more natural synchronous style but still execute in a distributed asynchronous manner if need be. An added benefit is that we can choose to execute the augmentation of the behavior local or remote, online or offline without changing a single line of code in the extension. This is aspect oriented programming (AOP) on a whole new level in which we alter both the space (location) and time (online, delayed, offline) aspects of a cross cutting concern whilst maintaining the calling context (thread stack) as well possible execution path histories (behavioral change sets).

Try to imagine your code executing simultaneous at multiple locations but within each location the triggered behavior associated with such code execution is potentially different and possibly isolated. This is separation of concern in terms of space and possibly time which I will come back to later.


Combining behavior replication with simulated playback allows us to move the integration extension code closer to computing resources whilst still keeping all state and code at a central point. There is no need to translate software execution behavior into events for processing by complex event process (CEP) platforms or business analytics. The actual behavior without the state side effects is replicated. This is as close to real-time as you can get and more importantly it is inlined within the execution behavior (the perception is the simulated runtime is real). Since the behavior is replicated we don’t just process the current event as is typical of messaging. We have the entire simulated execution behavior to reason about and in different ways within different simulated machines. Each mirrored simulated machine is an image of the source. But within each mirrored machine we can transform and filter the image and emit an entirely new execution behavior elsewhere. We can apply multiple cross cutting concerns to intercepted simulated behavior, each within a different isolated simulated machine. If a particular concern needs to take on a global dimension then we can replicate software behavior from multiple sources into a single simulated machine. The potential applications for this technology is HUGE. It could revolutionize the business analytics industry as well as monitoring, management, security,…

To provide a practical developer demonstration of this new approach I created a simple HelloWorld class that looped over a print() method. Strangely enough it did not print "Hello world!" to the terminal output but instead slept for 1 second.


Next I created a metering extension using our Probes Open API to intercept the entry (begin) and exit (end) call execution points into the HelloWorld.print() method. In the begin method of the ProbesIntroceptor, which is returned for probes matching simz.HelloWorld.print, I corrected the print() methods behavior by printing "Hello world!".


Here is a diagram showing the local call sequence when both the application and the extension are collocated. When the demo was executed "Hello world!" was printed multiple following the single printed line "This is real!". I added the "This is real!" print statement so that those attending the JavaOne talk could determine when the actual application code was loaded.


Next I started up a Simz JVM with the very same metering extension installed. I then re-executed the application but this time without the extension installed locally. In the application terminal only "This is real!" was printed. In the Simz terminal "Hello world!" was printed repeatedly and in synch with the applications execution of the print() method. I had successfully demonstrated that I could change the space aspect of the execution. I had moved the interception and its augmentation from the real application runtime to a simulated application runtime without change.


To demonstrate how to change the time aspect of the augmented execution I re-executed the application with our metering recorder enabled, then shutdown the application after a short period and finally played back the recording that had been created in a separate simulated JVM. This simulated JVM printed "Hello world!" a number of times. The ultimate in computation decoupling and yet the extension code was never aware of how I had changed space and time. Mirrors can create the illusion of magic. They allow us to see the world differently and from many viewpoints.


You can view a screen recording here. A video is also available on YouTube and ideally should be viewed in full screen HD mode.

Further Reading
Mirroring, Mindreading and Simulation of the (Java) Virtual Machine
Rewriting Application Performance Monitoring Histories with Record & Playback
Simulation and Time Synchronization of Application Memories