Cog is an evolving system. \u00c2\u00a0Some projects are being worked on, some are as yet just dreams. \u00c2\u00a0We’re interested in collaborators \ud83d\ude09 \u00c2\u00a0This page may help you determine where you can help.<\/p>\n
<\/p>\n
Spur is a new memory manager whose core is a more efficient object representation that has a single header format for both 64-bit and 32-bit implementations.<\/p>\n
Spur is released as Squeak 5.0, Newspeak and Pharo 5, and 64-bit Squeak 5.0 is in use, but green. \u00c2\u00a0There are still important missing\u00c2\u00a0components:<\/p>\n
– an incremental global mark-sweep-compact collector that avoids long pause times running a stop-the-world\u00c2\u00a0scan-mark-compact during interactive use.<\/p>\n
– an improved per-segment compaction algorithm to replace the second cut compaction algorithm (pig compact) that is slow and reorders objects.<\/p>\n
-\u00c2\u00a0a solution to the problem of free space in segments containing pinned objects at snapshot time (hopefully solved by the improved per-segment compaction algorithm)<\/p>\n
– A scheme to avoid garbage collecting large class libraries in “static” applications (this is what VisualWorks calls “Perm Save”). \u00c2\u00a0Spur’s segmentation could allow e.g. the first segment to be managed as a “perm segment” that would not be garbage collected.<\/p>\n
– image segment interoperability between Spur 32-bit and 64-bit versions and between Spur and previous Squeak versions. \u00c2\u00a0(It is hoped that such support would be done at the image level only without VM support).<\/p>\n
<\/p>\n
64-bit Spur is progressing. \u00c2\u00a0There is a functional system and a Cogit and StackInterpreter for x64 Linux & Mac OS X. \u00c2\u00a0Still required are<\/p>\n
– 64-bit VMs for Windows
\n– an ARMv8 backend for the Cogit (Tim would like to\u00c2\u00a0work on this; anybody with funding should contact he or me)<\/p>\n
<\/p>\n
Sista, the Speculative Inlining Small-talk Architecture, is a combination of an image-level adaptive optimizer and low-level Cogit support for performance counters and unsafe inline primitives, which together can generate much more efficient machine code implementations of often-executed codes. \u00c2\u00a0Scorch is the image level component, Cl\u00c3\u00a9ment’s SSA optimizer and dynamic deoptimizer. \u00c2\u00a0 Cl\u00c3\u00a9ment\u00c2\u00a0and\u00c2\u00a0Eliot are working on this. \u00c2\u00a0We want\u00c2\u00a0to release a first production version towards the end of\u00c2\u00a02016.<\/p>\n
<\/p>\n
The Cog VM is single-threaded, providing green threads to the Smalltalk level, as do most Smalltalk VMs. There is a prototype subclass of the CoInterpreter, CoInterpreterMT, which provides a Python-like multi-threaded VM where any number of threads can share the VM with only one running the VM at any one time. \u00c2\u00a0This uses an extremely simple low-level scheme designed by David Simmons for releasing and re-acquiring ownership of the VM. \u00c2\u00a0This results in any and all FFI calls being non-blocking since there is such a low overhead to making a non-blocking FFI call that all FFI calls can be non-blocking. \u00c2\u00a0Eliot has worked on this, implementing the prototype and the reentrant FFI plugin it requires. \u00c2\u00a0But this needs to be revived. \u00c2\u00a0It would be a really powerful enhancement.<\/p>\n
<\/p>\n
Complex ABIs such as x86-64 (where for example the contents of structs are scattered across available integer and floating-point argument registers) are difficult to implement via interpretation (where a signature is interpreted to marshal arguments for a specific call). \u00c2\u00a0For both efficiency and correctness a compiled implementation, where for example marshalling code is generated on first use of a given call in any run, is preferrable. \u00c2\u00a0While quite a few people are interested (Igor, Ronie, Eliot), and Ronie’s Lowcode support is being added to the Cogit, no one is actively working on the image-level ABI compiler. \u00c2\u00a0This is less important than anticipated because the existing FFI plugin has been successfully ported to support x64 on 64-bit Spur.<\/p>\n
<\/p>\n
The Cog VM, being derived from the standard Squeak VM, has an unsatisfactory idle implementation, with the background process calling a yield primitive that gives back time to the OS. \u00c2\u00a0This causes the VM to consume of the order of 3%-5% at idle. \u00c2\u00a0Instead the VM should block awaiting events when it has nothing to do. \u00c2\u00a0There are various attempts at an event-driven Squeak VM (e.g. for Android) but none of this has been integrated into Cog, nor has the idle issue been addressed. \u00c2\u00a0Closely related is to replace the use of select(2) for i\/o polling with kqueue(2)\u00c2\u00a0or\u00c2\u00a0epoll(2) on platforms that support it.<\/p>\n
<\/p>\n
Vassili Bykov has implemented a native Windows UI above Cog’s callback support. \u00c2\u00a0But a more comprehensive approach is possible, factoring out the GUI support in e.g. the Mac and Windows VMs and replacing it with an FFI-based implementation above the threaded FFI. \u00c2\u00a0Such a VM would be truly headless, containing no GUI code in the base VM.<\/p>\n
<\/p>\n
It would be useful to be able to embed a Smalltalk system running above Cog in other clients, e.g. as a DLL. \u00c2\u00a0Cog has callbacks, above which an API can be built to access Smalltalk, but lots of refactoring and repackaging of the VM sources is necessary to realise this.<\/p>\n
<\/p>\n
For a really cool project how about grabbing Bert Freudenberg’s VMMakerJS Squeak-vm-on-JavaScript, extracting the event handling and rendering part into a component and connecting it to the Cog VM via sockets to give us a really fast web plugin? \u00c2\u00a0This would be portable across browsers, and would decouple updating the VM from updating the plugin.<\/p>\n
<\/p>\n
While multi-threading seems like an obvious and important direction to take the system in, making the VM multi-threaded per-se does not provide any benefit before the Smalltalk image is made thread-safe and that is probably more work than providing a multi-threaded VM. \u00c2\u00a0Hence a potentially more profitable approach is to concentrate on federating multiple VMs running multiple images, communicating through the threaded FFI.<\/p>\n
<\/p>\n
Read-only object support\u00c2\u00a0is the ability to mark individual objects as read-only. \u00c2\u00a0This can be used to make\u00c2\u00a0literals immutable, and to provide efficient\u00c2\u00a0write-through support for orthogonal persistence schemes, and to implement debugging traps, etc. \u00c2\u00a0Cl\u00c3\u00a9ment has implemented the VM and Cogit support. \u00c2\u00a0So\u00c2\u00a0image level work can begin.<\/p>\n
<\/p>\n
Subversion is the current repository for generated Cog VM sources. \u00c2\u00a0This is seen as less desirable than a git repository for integration with CI. \u00c2\u00a0Moving Cog from subversion to git may seem straight-forward but needs to be done with tact to help people over the transition.<\/p>\n
<\/p>\n
Cog started off from Qwaq’s fork of the Squeak VM. \u00c2\u00a0As such, Cog and the Squeak VM’s ObjectMemory hierarchy differ in detail, and Cog’s Slang has changed considerably to accomodate the much more complex VM. \u00c2\u00a0Merging the two is desirable. \u00c2\u00a0We would also like to see an Interpreter VM for Spur.<\/p>\n