Hi all,
I'm proud to announce SqueakJS, a new Squeak VM that runs on Javascript:
http://bertfreudenberg.github.io/SqueakJS/
It was inspired by Dan's JSqueak/Potato VM for Java, and similarly only runs the old Squeak 2.2 mini.image for now. But I developed it inside the Lively Kernel, which allowed me to make a nice UI to look inside the VM (in addition to all the Lively tools):
It represents regular Squeak objects as Javascript objects with direct object references. SmallIntegers are represented as Javascript numbers, there is no need for tagging. Instance variables and indexable fields are held in a single array named "pointers". Word and byte binary objects store their data in arrays named "bytes" or "words". CompiledMethod instances have both "pointers" and "bytes". Float instances are not stored as two words as in Squeak, but have a single "float" property that stores the actual number (and the words are generated on-the-fly when needed).
For garbage collection, I came up with a hybrid scheme: the bulk of the work is delegated to the Javascript garbage collector. Only in relatively rare circumstances is a "manual" garbage collection needed. This hybrid GC is a semi-space GC with an old space and a new space. Old space is a linked list of objects, but newly allocated objects are not added to the list, yet. Therefore, unreferenced new objects will be automatically garbage-collected by Javascript. This is like Squeak's incremental GC, which only looks at objects in new space. The full GC is a regular mark-and-sweep: it's marking all reachable objects (old and new), then unmarked old objects get removed (a very cheap operation in a linked list), and new objects (identified by their missing link) are added to the old-space list. One nice feature of this scheme is that its implementation does not need weak references, which Javascript currently does not support.
This scheme also trivially supports object enumeration (Squeak's nextObject/nextInstance primitives): If the object is old, the next object is just the next link in the list. Otherwise, if there are new objects (newSpaceCount > 0) a GC is performed, which creates the next object link. But if newSpaceCount is 0, then this was the last object, and we're done.
The UI for now copies the Squeak display bitmap pixel-by-pixel to a typed array and shows it on the HTML 2D canvas using putImageData(). Clipboard copying injects a synthetic CMD-C keyboard event into the VM, then runs the interpreter until it has executed the clipboard primitive in response, then answers that string. This is because the web browser only allows clipboard access inside the copy/paste event handlers. You can drag an image file from your disk into the browser window to load it.
Besides running it on your desktop, you can install it as offline web app on an iPad:
On the iPad there is neither right-click nor command keys, but the menu is available on the inside of the flop-out scrollbars. It needs a fairly recent browser, too - it works in iOS 7, but apparently not in older ones. On Android it works in Chrome 31, but not quite as well (for example, the onscreen-keyboard does not come up on an Galaxy Note tablet).
The sources are on GitHub, and contributions are very welcome.
Have a great Christmas!
- Bert -
Wow. I expected that eventually someone would do this. Is it running the usual JSqueak 2.x image?
The potential here is unreal, man. We might be able to resurrect Scratch in Smalltalk if it can be run in browsers (especially on platforms like iOS where Flash is not present!)
Out of curiosity, do you have any benchies to share? It'd be nice to have a sense of what top of the line hardware and V8 can do with something like this in terms of performance.
Fantastic, Bert!
--Casey
On Fri, Dec 20, 2013 at 1:22 PM, Bert Freudenberg bert@freudenbergs.dewrote:
Hi all,
I'm proud to announce SqueakJS, a new Squeak VM that runs on Javascript:
http://bertfreudenberg.github.io/SqueakJS/
It was inspired by Dan's JSqueak/Potato VM for Java, and similarly only runs the old Squeak 2.2 mini.image for now. But I developed it inside the Lively Kernel, which allowed me to make a nice UI to look inside the VM (in addition to all the Lively tools):
It represents regular Squeak objects as Javascript objects with direct object references. SmallIntegers are represented as Javascript numbers, there is no need for tagging. Instance variables and indexable fields are held in a single array named "pointers". Word and byte binary objects store their data in arrays named "bytes" or "words". CompiledMethod instances have both "pointers" and "bytes". Float instances are not stored as two words as in Squeak, but have a single "float" property that stores the actual number (and the words are generated on-the-fly when needed).
For garbage collection, I came up with a hybrid scheme: the bulk of the work is delegated to the Javascript garbage collector. Only in relatively rare circumstances is a "manual" garbage collection needed. This hybrid GC is a semi-space GC with an old space and a new space. Old space is a linked list of objects, but newly allocated objects are not added to the list, yet. Therefore, unreferenced new objects will be automatically garbage-collected by Javascript. This is like Squeak's incremental GC, which only looks at objects in new space. The full GC is a regular mark-and-sweep: it's marking all reachable objects (old and new), then unmarked old objects get removed (a very cheap operation in a linked list), and new objects (identified by their missing link) are added to the old-space list. One nice feature of this scheme is that its implementation does not need weak references, which Javascript currently does not support.
This scheme also trivially supports object enumeration (Squeak's nextObject/nextInstance primitives): If the object is old, the next object is just the next link in the list. Otherwise, if there are new objects (newSpaceCount > 0) a GC is performed, which creates the next object link. But if newSpaceCount is 0, then this was the last object, and we're done.
The UI for now copies the Squeak display bitmap pixel-by-pixel to a typed array and shows it on the HTML 2D canvas using putImageData(). Clipboard copying injects a synthetic CMD-C keyboard event into the VM, then runs the interpreter until it has executed the clipboard primitive in response, then answers that string. This is because the web browser only allows clipboard access inside the copy/paste event handlers. You can drag an image file from your disk into the browser window to load it.
Besides running it on your desktop, you can install it as offline web app on an iPad:
On the iPad there is neither right-click nor command keys, but the menu is available on the inside of the flop-out scrollbars. It needs a fairly recent browser, too - it works in iOS 7, but apparently not in older ones. On Android it works in Chrome 31, but not quite as well (for example, the onscreen-keyboard does not come up on an Galaxy Note tablet).
The sources are on GitHub, and contributions are very welcome.
Have a great Christmas!
- Bert -
The point is pretty much that it only takes two clicks to run the benchmark yourself:
http://bertfreudenberg.github.io/SqueakJS/demo/simple.html
Interestingly, Safari is about twice as fast as Chrome, and gets even better when it "warmed up".
This VM does have the usual method cache, at cache, and primitive short cuts, but is otherwise a completely unoptimized interpreter. Many of the optional primitives are not yet implemented.
Here is the VM source, just a single file (because in Lively I see it split up anyway):
https://github.com/bertfreudenberg/SqueakJS/blob/master/vm.js
I agree about the potential, just don't expect too much at this stage. It is just a couple of weeks old, as you can see from the change log.
- Bert -
On 21.12.2013, at 05:20, Casey Ransberger casey.obrien.r@gmail.com wrote:
Wow. I expected that eventually someone would do this. Is it running the usual JSqueak 2.x image?
The potential here is unreal, man. We might be able to resurrect Scratch in Smalltalk if it can be run in browsers (especially on platforms like iOS where Flash is not present!)
Out of curiosity, do you have any benchies to share? It'd be nice to have a sense of what top of the line hardware and V8 can do with something like this in terms of performance.
Fantastic, Bert!
--Casey
On Fri, Dec 20, 2013 at 1:22 PM, Bert Freudenberg bert@freudenbergs.de wrote:
Hi all,
I'm proud to announce SqueakJS, a new Squeak VM that runs on Javascript:
http://bertfreudenberg.github.io/SqueakJS/
It was inspired by Dan's JSqueak/Potato VM for Java, and similarly only runs the old Squeak 2.2 mini.image for now. But I developed it inside the Lively Kernel, which allowed me to make a nice UI to look inside the VM (in addition to all the Lively tools):
<SqueakJS-Lively.png>
It represents regular Squeak objects as Javascript objects with direct object references. SmallIntegers are represented as Javascript numbers, there is no need for tagging. Instance variables and indexable fields are held in a single array named "pointers". Word and byte binary objects store their data in arrays named "bytes" or "words". CompiledMethod instances have both "pointers" and "bytes". Float instances are not stored as two words as in Squeak, but have a single "float" property that stores the actual number (and the words are generated on-the-fly when needed).
For garbage collection, I came up with a hybrid scheme: the bulk of the work is delegated to the Javascript garbage collector. Only in relatively rare circumstances is a "manual" garbage collection needed. This hybrid GC is a semi-space GC with an old space and a new space. Old space is a linked list of objects, but newly allocated objects are not added to the list, yet. Therefore, unreferenced new objects will be automatically garbage-collected by Javascript. This is like Squeak's incremental GC, which only looks at objects in new space. The full GC is a regular mark-and-sweep: it's marking all reachable objects (old and new), then unmarked old objects get removed (a very cheap operation in a linked list), and new objects (identified by their missing link) are added to the old-space list. One nice feature of this scheme is that its implementation does not need weak references, which Javascript currently does not support.
This scheme also trivially supports object enumeration (Squeak's nextObject/nextInstance primitives): If the object is old, the next object is just the next link in the list. Otherwise, if there are new objects (newSpaceCount > 0) a GC is performed, which creates the next object link. But if newSpaceCount is 0, then this was the last object, and we're done.
The UI for now copies the Squeak display bitmap pixel-by-pixel to a typed array and shows it on the HTML 2D canvas using putImageData(). Clipboard copying injects a synthetic CMD-C keyboard event into the VM, then runs the interpreter until it has executed the clipboard primitive in response, then answers that string. This is because the web browser only allows clipboard access inside the copy/paste event handlers. You can drag an image file from your disk into the browser window to load it.
Besides running it on your desktop, you can install it as offline web app on an iPad:
<SqueakJS-iPad.jpg>
On the iPad there is neither right-click nor command keys, but the menu is available on the inside of the flop-out scrollbars. It needs a fairly recent browser, too - it works in iOS 7, but apparently not in older ones. On Android it works in Chrome 31, but not quite as well (for example, the onscreen-keyboard does not come up on an Galaxy Note tablet).
The sources are on GitHub, and contributions are very welcome.
Have a great Christmas!
- Bert -
This is absolutely beautiful!
Performance figures are rather modest: Safari: 3,401,360 bytecode/s 127,111 sends/s Firefox: 4,232,804 bytecode/s 152,003 sends/s Chrome: 1,860,465 bytecode/s 76,859 send/s StackVM: 623,250,152 bytecode/s 13,392,546 sends/s
But still, MVC is _very_ usable. I could even set display depth to 32bpp, and play with mandalas and such in full color. Wonderful!
This makes me think... Maybe MVC could still be useful as a low overhead UI for servers that usually run headless, very low power hardware, etc...
Cheers, Juan Vuletich
Wow, okay made it to a real computer and tried it out. Fabulous. Considering an interpreter running in another high level language, the performance is amazing. I'm floored.
Juan: I would LOVE to see MVC for headless servers and systems too low end to run Morphic well. One of the things I'd like to be able to do in Squeak/etc is to be able to unload Morphic. Alas, I have too many hobbies. I wish I had a good chunk of time to devote to resurrecting MVC for Cuis. But I'm rambling off-topic.
This is just SO cool.
On Sat, Dec 21, 2013 at 8:50 AM, J. Vuletich (mail lists) < juanlists@jvuletich.org> wrote:
This is absolutely beautiful!
Performance figures are rather modest: Safari: 3,401,360 bytecode/s 127,111 sends/s Firefox: 4,232,804 bytecode/s 152,003 sends/s Chrome: 1,860,465 bytecode/s 76,859 send/s StackVM: 623,250,152 bytecode/s 13,392,546 sends/s
But still, MVC is _very_ usable. I could even set display depth to 32bpp, and play with mandalas and such in full color. Wonderful!
This makes me think... Maybe MVC could still be useful as a low overhead UI for servers that usually run headless, very low power hardware, etc...
Cheers, Juan Vuletich
On Sat, Dec 21, 2013 at 01:50:26PM -0300, J. Vuletich (mail lists) wrote:
This is absolutely beautiful!
Performance figures are rather modest: Safari: 3,401,360 bytecode/s 127,111 sends/s Firefox: 4,232,804 bytecode/s 152,003 sends/s Chrome: 1,860,465 bytecode/s 76,859 send/s StackVM: 623,250,152 bytecode/s 13,392,546 sends/s
But still, MVC is _very_ usable. I could even set display depth to 32bpp, and play with mandalas and such in full color. Wonderful!
This makes me think... Maybe MVC could still be useful as a low overhead UI for servers that usually run headless, very low power hardware, etc...
I think that the lightweight MVC interface was important for demonstrating the RoarVM for exactly this reason.
http://news.squeak.org/tag/roarvm/
Dave
From 10/27/1999
On a Iivx which is a 32mhz machine 68030 with an older VM 2.6 I got 248,632 bytecodes/sec and 10,885 sends a second.
A Quadra 950 a 66Mhz 68040 with Linux 2.0.38 does 1,219,512 and 58,368. But I found the GCC compiler under Linux produced code that was about 50% better than the MetroWerks CW version. On the same machine under Mac OS it only does 859,845 and 40,106. At this speed its quite workable and you can do most things with Squeak.
After upgrading my IIvx with a 50Mhz 68030 CPU upgrade card and using the latest VM I get 504,286 and 17,958. At this speed things are slow but not too bad, but don't attempt any 3D work. Just think back 6 years and the response time doesn't really hurt. It depends on what you want to do, MVC work is just fine.
PS a SE/30 does 135,135 and 4,722 which I deem to be rather slow! But having the latest VM work on this machine is a tribute to all involved.
BTW my PowerBook 500Mhz does 46,613,255 bytecodes/sec; 1,542,241 sends/sec using the latest VM with my modification compiled with CW Pro 5.
On Sat, Dec 21, 2013 at 11:50 AM, J. Vuletich (mail lists) < juanlists@jvuletich.org> wrote:
This is absolutely beautiful!
Performance figures are rather modest: Safari: 3,401,360 bytecode/s 127,111 sends/s Firefox: 4,232,804 bytecode/s 152,003 sends/s Chrome: 1,860,465 bytecode/s 76,859 send/s StackVM: 623,250,152 bytecode/s 13,392,546 sends/s
But still, MVC is _very_ usable. I could even set display depth to 32bpp, and play with mandalas and such in full color. Wonderful!
This makes me think... Maybe MVC could still be useful as a low overhead UI for servers that usually run headless, very low power hardware, etc...
Cheers, Juan Vuletich
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Casey Ransberger -
David T. Lewis -
J. Vuletich (mail lists) -
John McIntosh