[Vm-dev] squeak.cog.spur-sunos32x86

Sat Mar 28 21:17:24 UTC 2020

Hi Stes,

>> On Mar 28, 2020, at 10:07 AM, stes <stes at telenet.be> wrote:
> 

Congrats on building a functional vm!! As discussed can you please create just a build directory, build.sunos32x86, populated with at least build directories for squeak.cog.spur squeak.cog.v3?  You can simply copy build.linux32x86 and change the mvm files.

The OpenSmalltalk-vm site is for source only.  We can get CI servers to build and host binaries.

> With beginner, I mean that at least I'm outsider regarding such issues as
> "classic vm" versus "opensmalltalk vm" etc.
> 
> It's a little confusing that there are multiple squeak vm's.

Mea culpa.

You can read a lot of the rational and history for the evolution to the current Spur 5.x VM/GC/Object Representation in this paper, [1] and on my blog site, mirandabanda.org, as well as by reading the 5.0 release notes in the Welcome workspace. Here is a brief summary.

The first Squeak vm series, as described in the Back To The Future paper [2], is a classic context interpreter, with a bytecode set very close to the blue book [3].  In particular it allocates a Context object in each non-primitive send, has non-reentrant blocks, see [4], and a single linear heap with a slow pointer-reversal GC.  This is the classical vm and in open-Smalltalk and Squeak trunk we use the name V3 to refer to this bytecode set and this object representation.

In 2008 I was taken on by Qwaq, a startup set up by some Squeak principals, notably Andreas Raab, applying Croquet to business communication.  My job was to speed up the Back To The Future VM.  This was accomplished in two stages.

Stage one was a StackInterpreter that used my version of the Deutsch, Schiffman [5] lazy context creation scheme to eliminate context overhead, and introduced a few new bytecodes to provide reentrant blocks (because this yields much better context-to-stack mapping [6]).  In opensmalltalk these are built in directories marked dialect.stack.objrep, eg squeak.stack.v3.

Stage two was a JIT version of the same bytecode set and object representation, see [7][8]. In opensmalltalk these are built in directories marked dialect.cog.objrep, eg squeak.cog.v3.

Squeak migrated to this slightly different object representation and bytecode set in about 2012/13 and was the 4.0 release.  The StackInterpreter VMs are useful when on iPhone where jitting is forbidden for non-Apple applications.

From 2011 until 2018 I worked at Cadence where Newspeak, built above Squeak Smalltalk, was used to implement tools for SoaC phone design.  In 2013 I started working on Spur [9][10][11] which is a new garbage collection and object representation scheme for Smalltalk, including a much more comprehensive support of 64-bits, a segmented heap that can grow and shrink, support for pinning and read-only objects, and much faster become.  I was joined in this by Clément Béra who has, apart from being a fabulous collaborator and friend, designed an incremental compactor for Spur [12] which we hope to put into production in the next (very) few years (it also needs an incremental mark-sweep collector).

In opensmalltalk these are built in directories marked dialect.vmarch.spur, eg squeak.cog.spur.  Spur provides about a -40% speedup on average (code takes 60% of the time it takes on a Cog V3 vm) but some codes are much faster.  Eg Spur supports immediate characters and do widestring access is much faster.  Squeak migrated to Spur in 2016 ish and is the 5.x series.

In parallel Clément and I collaborate(d) on an adaptive optimizer to further improve performance, I hope by at least -66.6%.  The architecture is called Sista, for Speculative Inlining Smalltalk Architecture, and the image-level optimiser is called Scorch.  See [13].  Clément produced an alpha 32-bit release for Pharo.  Sista is currently under development.  See [14]. This is the subject of Clément’s PhD [15].

In opensmalltalk these are built in directories marked dialect.sista.objrep, eg squeak.sista.spur

HTH

> Also although I have a working binary now, which seems to be capable of
> running an image like:
> 
> bash-4.4$ bin/squeak Squeak6.0alpha-19547-32bit.image 
> 
> the latest 6.0alpha image,  it seems buggy since I suffer from "update"
> problems for screen drawing,
> when opening a browser for example, I have screen update problems/issues, so
> it is just a first attempt of a "port".
> 
> In some sense I think the Solaris platform (based on what I saw on the
> "classic vm") was always supported in the past, so it is not a "new" port, 
> it is just making sure it keeps working.
> 
> Also I have a message:
> 
> bash-4.4$ bin/squeak Squeak5.2-18221-32bit.image      
> 
> *pthread_setschedparam failed: Not owner*
> This VM uses a separate heartbeat thread to update its internal clock
> and handle events.  For best operation, this thread should run at a
> higher priority, however the VM was unable to change the priority. 
> 
> which I have to look into

The issue is that the heartbeat thread, whose job it is to periodically get the vm to exit JITted machine code to poll for input and timer events, must run at a higher priority than the main vm thread.  If it does not then it won’t interrupt the main thread at regular intervals.  If Solaris doesn’t allow user processes to create higher priority threads (which, IIRC, was also the case with pre 2.16 Linux kernels), then a barely acceptable alternative is to use an ITIMER heartbeat.  This is not nice to use as the ITIMER signal can interrupt FFI calls etc.

References

1. Eliot Miranda, Clément Béra, Elisa Gonzalez Boix, and Dan Ingalls. “Two Decades of Smalltalk VM Development: Live VM Development Through Simulation Tools.” In Proceedings of the 10th ACM SIGPLAN International Workshop on Virtual Machines and Intermediate Languages, 57–66. VMIL 2018. New York, NY, USA: ACM, 2018.http://doi.acm.org/10.1145/3281287.3281295.

2. Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay. “Back to The Future: The Story of Squeak, A Practical Smalltalk Written in Itself.” In Proceedings of the 12th ACM SIGPLAN Conference on Object-Oriented Programming (OOPSLA) 1997, 318–26, 1997.https://doi.org/10.1145/263698.263754.

3. Part 4 of http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf

4. http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/

5. Deutsch schiffmann

6. http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/

7. http://www.mirandabanda.org/cogblog/2011/03/01/build-me-a-jit-as-fast-as-you-can/

8. http://www.mirandabanda.org/cogblog/2011/03/04/an-arranged-marriage/

9.  http://www.mirandabanda.org/cogblog/2013/09/05/a-spur-gear-for-cog/

10. http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-read-barrier/

11. http://www.mirandabanda.org/cogblog/2014/02/08/primitives-and-the-partial-read-barrier/

12. Lazy pointer update for low heap compaction pause times
October 2019
DOI: 10.1145/3359619.3359741
Conference: the 15th ACM SIGPLAN International Symposium

13. Clément Béra, Eliot Miranda, Tim Felgentreff, Marcus Denker, and Stéphane Ducasse. “Sista: Saving Optimized Code in Snapshots for Fast Start-Up.” In Proceedings of the 14th International Conference on Managed Languages and Runtimes, 1–11. ManLang 2017. New York, NY, USA: ACM, 2017.http://doi.acm.org/10.1145/3132190.3132201.

14. http://forum.world.st/how-can-I-build-a-sista-spur-64-vm-tt5113715.html#a5113828

15. Sista: a Metacircular Architdcture for Runtime Optimisation Persistence https://hal.inria.fr/tel-01634137/document

> 
> 
> 
> 
> --
> Sent from: http://forum.world.st/Squeak-VM-f104410.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200328/36e6c593/attachment-0001.html>