[Vm-dev] Re: Different bytecode set per process

[Clément Bera]

I believe it's not about having a different bytecode set per process, I
believe you want some process not to be able to edit the heap but to do
computation only. So the process has access to a restricted bytecode set
(not inst var store for example) and a restricted set of primitives (no
#at:put:).

STM is very interesting indeed. In the RSqueak/VM, how did you change the
process scheduler ? Did you mark specific processes so they belong to a
specific native thread ? I see that you added primitives for atomic blocks
of code and to fork a process in another native thread.

On Wed, Jun 8, 2016 at 10:07 AM, timfelgentreff <timfelgentreff at gmail.com>
wrote:

>
> Hi Ben,
>
> We once experimented with STM to run Squeak Processes on multiple cores
> without any restrictions to the bytecodes. Due to the STM foundations, any
> conflicts are resolved automatically (with quite a bit of performance
> impact
> as more and more conflicts occur). But for algorithms that do not share
> data
> structures (except an output of some kind) we did actually see quite a bit
> of speedup when scaling over multiple cores - without any changes to the
> image.
>
> Now, if we had such a bytecode set restriction that could be attached to a
> process, this experiment could become very interesting again.
>
> Best,
> Tim
>
>
> Ben Coman wrote
> > On Wed, Jun 8, 2016 at 6:07 AM,  &lt;
>
> > commits at .squeak
>
> > &gt; wrote:
> >>
> >> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
> >> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1884.mcz
> >>
> >> Fix multiple bytecode set selection in the Spur 64-bit VM, which must
> use
> >> signedIntFromLong64 to test for a negative header.
> >
> >
> > Just a strange spark of an idea thats been floating in my head for a
> > while regarding use of multiple CPU cores (it doesn't need a response
> > - it just helps quiet my thoughts to share them...)
> >
> > The main problem with multiple native threads is concurrent
> > modification objectmemory, plus most of the Image is not designed for
> > such parallel execution,
> > but...
> >
> > What if you could have a bytecode set that had all the bytecodes which
> > modify objectmemory stripped out, so that only stack operations were
> > permitted. And if a forked Smalltalk Process could be restricted to
> > that bytecodeset (swapping the bytecode set when the Process is woken
> > in #transferTo:), then you kindof enforce a functional style of
> > programming for that Process that could not interfere with
> > objectmemory.
> >
> > This might be suitable for some forms of intensive data processing
> > that crunch a lot of data down to a small result.  Maybe it would be
> > difficult for such a forked Process to deal with the main UI Process
> > changing objectmemory underfeet.
> >
> > cheers -ben
>
>
>
>
>
> --
> View this message in context:
> http://forum.world.st/Different-bytecode-set-per-process-tp4899760p4899809.html
> Sent from the Squeak VM mailing list archive at Nabble.com.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160608/e0d25de9/attachment.htm