Skip to content

Integrate SimulationStudio#54

Merged
tom95 merged 3 commits intohpi-swa:masterfrom
LinqLover:SimulationStudio
Nov 1, 2021
Merged

Integrate SimulationStudio#54
tom95 merged 3 commits intohpi-swa:masterfrom
LinqLover:SimulationStudio

Conversation

@LinqLover
Copy link
Copy Markdown
Collaborator

This PR switches the existing simulation features of Sandblocks to SimulationStudio. Concretely, this affects the following classes:

  • SBStSandboxSimulator: Switched to SimulationStudio's Sandbox.
  • SBStReachabilitySimulator: Switched from SBStSimulator to SimulationStudio's SimulationContext. Refined reachability detection to match every single PC.
  • SBTypeCollectSimulator:: Switched from InstructionClient to SimulationStudio's SimulationContext.
  • The baseline is updated accordingly.

Open todos:

  • Migrate SBStTracingSimulator too? I would be willing to do so, but without any entry point or test, I don't dare. We can also leave this class as-is if this is not important.
  • Delete the old simulator classes? I will not do this without your explicit request. :-)

Why SimulationStudio? (may contain traces of self-advertising 👀)
  • SimulationStudio reuses and makes extensible the original meta-interpreter of Squeak. As a consequence, no reinvention of the wheel (as it is done in InstructionClient) is required, deduplication is avoided, and code will not come out of sync if the execution semantics of Squeak change (i.e., when a new primitive is introduced). All thisContext facilities that are required for proper meta-programming tasks such as exception handling are available to the simulated code as usually.

  • SimulationStudio's sandbox enforces fewer limitations while simulating the code. If any side effect is detected, the simulation does not stop, but the side effect is simulated in a separate object space, visible only to the simulated stack frames. Most VM primitives have been annotated manually to support a maximum number of side-effect-free VM operations. Even interaction with the caller stack is safely possible, for instance:

    [Sandbox evaluate: [self inform: #foo]] valueSuppressingAllMessages.

    At the same time, no outbreak is known yet. If you can find any, please keep them coming! :-)

  • SimulationStudio offers better tooling; for instance, you can debug the simulated code in a debugger like this:

    SBStReachabilitySimulator newFrom: [SBReachabilitySimulatorTest new exampleMethod] asContext)
    	store: SBReachabilityColorPolicy new;
    	debug.

For even more advertising, check out my way too long announcement email here: [ANN] SimulationStudio and sandboxed execution for Squeak. ;-)

…io's SimulationContext

SimulationContext comes with a higher precision (uses Squeak's built-in meta-interpreter instead of duplicated code) and better tooling (try this: (SBStReachabilitySimulator newFrom: [SBReachabilitySimulatorTest new exampleMethod] asContext) store: SBReachabilityColorPolicy new; debug).
@tom95
Copy link
Copy Markdown
Collaborator

tom95 commented Nov 1, 2021

Very nice changes, thank you for the PR! I'll go ahead and merge it as-is and do the open cleanup items you mentioned in a follow-up commit :)

@tom95 tom95 merged commit 0845a8d into hpi-swa:master Nov 1, 2021
@LinqLover LinqLover deleted the SimulationStudio branch November 1, 2021 12:23
@LinqLover
Copy link
Copy Markdown
Collaborator Author

Yahoo, glad you like it! :D

@LinqLover
Copy link
Copy Markdown
Collaborator Author

Oh no, this broke the CI - which was unfortunately not enabled for pull requests :(

https://github.com/tom95/sandblocks/runs/4067603490?check_suite_focus=true#step:4:167

Taking a look at it ...

LinqLover added a commit to LinqLover/sandblocks that referenced this pull request Nov 1, 2021
@LinqLover
Copy link
Copy Markdown
Collaborator Author

Argh, SimulationStudio is not compatible with Squeak 5.3 at all. I'm going to spike how complex porting it back will be. For Trunk, all tests pass.

@tom95
Copy link
Copy Markdown
Collaborator

tom95 commented Nov 1, 2021

If it seems more difficult, we could make the dependency optional and only load it in trunk. Would probably mean that we need to isolate the dependencies in Sandblocks in a separate package.

@LinqLover
Copy link
Copy Markdown
Collaborator Author

Hmm, this sounds not too elegant, and it would mean that Sandblocks's simulator features would either be unavailable in 5.3 or that we would need to keep the old version of their implementation working for 5.3, wouldn't it?

I'll spend some more time trying to find out how strongly SimulationStudio is actually coupled to Squeak 6.0Alpha, you can track the progress here (but I will keep you up to date in this thread, too, of course). However, this might take me some days, so if a green CI is important to you, you could revert this PR temporarily ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants