[Vm-dev] Ideas on cheap multi-threading for Squeak / Pharo ? (from Tim's article)

Ben Coman btc at openinworld.com
Tue Jan 31 23:37:10 UTC 2017

On Wed, Feb 1, 2017 at 2:08 AM, Ronie Salgado <roniesalg at gmail.com> wrote:
> Hi All,
>> Threads are more useful when one needs high performance and low latency in an application that runs in a single computer. High performance video games and (soft) realtime graphics are usually in this domain.
>> I know you're working with high performance video games. If you would introduce multi-threading in Squeak/Pharo, how would you do it ? Especially, do you have a design in mind that does not require to rewrite all the core libraries ?
> For Pharo I am going to the GPGPU route, using either OpenCL or a low level graphics API (Vulkan, D3D 12 or Metal). This way, I do not have to change the VM or Pharo for using the many threads present in the GPGPU. I am modifying Pharo and the VM with other purposes, such as being able to submit lot of data to the GPU so that it can be kept busy.
> For actual CPU side multithreading, I am abandoning Pharo and the VM by making an Ahead of Time Compiler(something similar to Bee Smalltalk), where I am using the OpalCompiler as a frontend, and a SSA based intermediate representation which is very similar to the one offered by LLVM, but written in Pharo. I had to make this SSA IR to be able to generate the shaders for Vulkan from Pharo, so for this AoT I am just reusing it by adding a machine code backend. With my framework I am able to generate an elf32 or an elf64 that can be linked with any C library directly, such as a minimalistic runtime( https://github.com/ronsaldo/slvm-native ) for providing Smalltalk facilities such as message sends, object allocation, GC, segmented stack, etc.
> I have already gotten some things working like message sends, the segmented stack, block closure creation and activation. For the object model, I am using the Spur object model, but with some slight modifications. Object interiors are aligned to 16 bytes, for being able to use SSE instructions. There is a small preheader for implementing the LISP2 GC algorithm (I choose it by its simplicity), become and heap management. The preheader is not used by generated code, except for serializing objects in the object file. I changed the CompiledMethod object type for having generic mixed oop and native data objects. For GC and multithreading, I will be just stopping the whole world in safe points and doing GC in a single thread. By disabling the GC, the user could be scheduling the GC to happen in non user perceived times, such as just after sending a frame rendering command.
> AoT compilation of Smalltalk is going to make modifications to method dictionaries a very rare operation, because you cannot AoT compile methods on runtime time, so you do not need the compiler in a shipping application. This places the burden of thread safetyness to a small number of places that can be protected explicitly by using some Mutexes.
> My plan with this infrastructure is leaving Pharo and the standard VM as a game prototyping and development environment, but doing the actual deployment by using this  very experimental Ahead of Time compiler, and the minimalistic Smalltalk runtime.

Thanks for that detailed rundown. Very interesting stuff.  Just
curious if you would keep Pharo as a user scripting engine?  Also are
you planning any facility to spawn your SLVM directly from Pharo, and
perhaps implementing server-side requirement for PharmIDE so you debug
your SLVM images from Pharo?

cheers -ben

More information about the Vm-dev mailing list