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

Yoshiki Ohshima Yoshiki.Ohshima at acm.org
Tue Mar 16 22:48:52 UTC 2021


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>
wrote:

> 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
>>
>>
>>

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


More information about the Squeak-dev mailing list