On Tue, Mar 16, 2021 at 9:52 AM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

> One more question: Do you know where I can find the Smalltalk
> implementation of worlds? Is there any at all? The abstract in ResearchGate
> mentions this but is not addressed in the paper ...
>
Well luckily one of the authors is still on this list ...

Looks really interesting and useful!

Vanessa

> Best,
>
> Christoph
> <http://www.hpi.de/>
> ------------------------------
> *Von:* Thiede, Christoph
> *Gesendet:* Dienstag, 16. März 2021 15:10:37
> *An:* squeak-dev at lists.squeakfoundation.org
> *Betreff:* AW: [squeak-dev] [ANN] SimulationStudio and sandboxed
> execution for Squeak
>
>
> Hi Subbu, thanks a lot for your thoughts! :-)
>
>
> > I am not sure if you have read Warth's research at VPRI
>
>
> No, I have not. Looks very interesting, I will read this!
>
> The only literature I had found on this (I have to admit that I did not
> spend much time on research) was this one:
> https://wiki.squeak.org/squeak/uploads/2074/sandbox.pdf It mentions a
> number of problems but does not come up with a simulation solution, so it
> would exclusively lock your image, I guess.
>
> > 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.
>
> Yeah, integrating the sandbox partially into the VM would make things
> faster, of course ... I haven't made any attempts in this direction for two
> reasons: First because I, honestly, still did not find the time for getting
> started with VMMaker, and second because while I know that the VM is
> written in a Smalltalk dialect as well, it hurts me a bit that it lacks the
> liveness of manipulating everything from within the running image. By the
> way, is there already some research about unioning these two worlds in
> order to reprogram the VM from within the image that is running in it? I
> would love this.
>
> What are white-outs? I could not find any reference on this.
>
> > 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.
>
> Actually, my current Sandbox approach does not even intend to "commit"
> changes back to the rest of the image (rather to work like a Docker
> container in small). Thus my goal would rather be to virtualize all
> physical operations but keeping the effects back from the real physical
> devices. For filesystem accesses, for example, I thought about redirecting
> all write operations to a copy of the files in a special folder ... Not
> sure how far this approach would work well, though.
>
> For some I/O primitives, however, virtualization is rather easy. For
> example, when writing on the global Display, you can simply copy this
> object like any other object into your sandbox space/world. However, other
> primitives, such as from the FilePlugin, operate on state is managed
> outside of the image ...
>
> Best,
> Christoph
>
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von K K Subbu <kksubbu.ml at gmail.com>
> *Gesendet:* Dienstag, 16. März 2021 14:21:16
> *An:* squeak-dev at lists.squeakfoundation.org
> *Betreff:* Re: [squeak-dev] [ANN] SimulationStudio and sandboxed
> execution for Squeak
>
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210316/e77ab241/attachment.html>