[Vm-dev] Different bytecode set per process

[Ben Coman]

On Wed, Jun 8, 2016 at 6:07 AM,  <commits at source.squeak.org> 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