[squeak-dev] [ANN] SimulationStudio and sandboxed execution for Squeak

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Tue Mar 16 23:38:46 UTC 2021


My image hangs when loading Greases ... Can you recommend an older version of Squeak which is officially supported? :-)


Best,

Christoph

<http://www.hpi.de/>
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
Gesendet: Mittwoch, 17. März 2021 00:20:53
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [ANN] SimulationStudio and sandboxed execution for Squeak

W2Compiler, right? It took sometime to dig it up but it is in the Grease package in the directory.  The main things is to compile AssingmentNode into a message call, and to avoid conflict such accessors were prefiexed with "wiv666" ("world instance variable 666") The majority of job is done by the W2Parser.

On Tue, Mar 16, 2021 at 3:55 PM Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>> wrote:

Thanks! Unfortunately, it's referring to a WCompiler which apparently is not part of the mcz file ...


Best,

Christoph

<http://www.hpi.de/>
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von Yoshiki Ohshima <Yoshiki.Ohshima at acm.org<mailto:Yoshiki.Ohshima at acm.org>>
Gesendet: Dienstag, 16. März 2021 23:48:52
An: Vanessa Freudenberg
Cc: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] [ANN] SimulationStudio and sandboxed execution for Squeak

Hi!

We still maintain the packages from VPRI.  Looking at the directory, we have quite a few versions of Worlds.  So there is a chance that it does something.

http://tinlizzie.org/updates/exploratory/packages/

On Tue, Mar 16, 2021 at 1:59 PM Vanessa Freudenberg <vanessa at codefrau.net<mailto:vanessa at codefrau.net>> wrote:
On Tue, Mar 16, 2021 at 9:52 AM Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de<mailto: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<mailto: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<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von K K Subbu <kksubbu.ml at gmail.com<mailto:kksubbu.ml at gmail.com>>
Gesendet: Dienstag, 16. März 2021 14:21:16
An: squeak-dev at lists.squeakfoundation.org<mailto: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




--
-- Yoshiki




--
-- Yoshiki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210316/05f2cb15/attachment.html>


More information about the Squeak-dev mailing list