On 16/03/21 4:51 pm, Thiede, Christoph wrote:
> Hi all! :-)
> 
> 
> I'm very excited to finally share my new project with you today, which I 
> call *SimulationStudio* and have made available on GitHub under [1]. Its 
> primary function is to provide an inheritable 
> *SimulationContext* subclass of Context that makes it easy to simulate 
> entire call trees while customizing the execution or installing custom 
> hooks for various tracing and measurement purposes. Another 
> accomplishment is the *Sandbox* which allows you to run arbitrary 
> Smalltalk code in an isolated environment, separating any side effects 
> that occur during the simulation from the rest of the image.

This is an amazing development!

I am not sure if you have read Warth's research at VPRI:

World: Controlling the Scope of Side Effects by A Warth et. all,

 
https://www.researchgate.net/publication/221496497_Worlds_Controlling_the_Scope_of_Side_Effects

Worlds is like your Sandbox. It also had a commit method to propagate 
state changes from the child to the parent. This is useful when a method 
modifies multiple state variables subject to strong invariants. A method 
may open a World, make changes and then verify invariants are preserved 
before committing the changes and closing the World.

> *Limitations and challenges*
> 
> Well, first of all ... *performance.* :-) Some recent measurements that 
> I have run have shown that the simulator reaches about 0.1 percent (sic) 
> of the speed of the VM executor, depending on the domain and the 
> distribution of bytecode operations.

I expect efficiency to improve if VM (e.g. object memory) exposes 
primitives for object spaces with copy-on-write and white-outs (for 
objects finalized in child space but not in parent). A sandbox could 
carve out an object space to hold modified/deleted objects and then 
either commit to parent or dispose it off on close. ObjectMemory already 
has support for multiple spaces (e.g. old and young). It needs to be 
exposed, with lots of care, to ST-side code.

> Another challenge is the *handling of primitive operations* during the 
> sandbox execution.

Handling primitives, particularly those that involve physical i/o, is a 
difficult problem. This is typically solved by using virtualization and 
double buffering (e.g. display or input). It is ok to work with 
non-volatile state variables for the first cut and then introduce 
virtualization for transactional access.

Regards .. Subbu