On Wed, Jan 14, 2015 at 3:15 AM, Ben Coman <btc@openinworld.com> wrote:

On Wed, Jan 14, 2015 at 11:39 AM, Joerg Beekmann, DeepCove Labs <joerg@deepcovelabs.com> wrote:
Hi

I've been exploring the possibility of hosting the Squeak/Pharo VM on MirageOS. MirageOS is a Unikernal or  "Library OS" where rather than creating an executable to be run on Linux the compiler analyses dependencies right down through the device drivers and creates a kernel that can be booted on Amazon AWS EC2.
    http://www.openmirage.org/
    http://queue.acm.org/detail.cfm?id=2566628
    http://blog.acolyer.org/2015/01/13/unikernels-library-operating-systems-for-the-cloud/

It seems to me that having a Smalltalk hosed in this environment would be quite useful on a number of fronts:
* A simple build and deploy of Smalltalk to the cloud. The Mirage group is building unikernals from sources and then because they are small committing the entire kernel to GitHub and then pushing the kernel to AWS EC2. Web sites and APIs are an obvious application.  http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/.
* Smalltalk on small devices. The Mirage group is running Xen with mirage on small Intel and ARM boards. See http://openmirage.org/blog/announcing-mirage-20-release/.
* These kernels can be very small, on the order of 0.25Meg for minimal HTTP servers with boot times in the ms range. A project called Jitsu https://github.com/MagnusS/jitsu modifies a DNS server to boot kernels in response to socket requests. The system making the request is unaware of the boot.
* The Mirage group envisions thousands of kernels running on a single Hypervisor with his speed inter-kernel communications. See http://openmirage.org/blog/update-on-vchan. The facilitates Smalltalk systems consisting of a swarm of communicating images where each image is single threaded and concurrency is via message passing.

I've corresponded with the MirageOS group asking if they thought a language VM could be hosted on Mirage. The discussion is here: http://lists.xenproject.org/archives/html/mirageos-devel/2015-01/msg00053.html. Assuming we understood each other it seems the answer is "yes that should be possible".

My question is what would be involved on the Smalltalk side? I presume the effort is going to be mostly in the VM. Based on the conversation on the Mirage list I think the VM will need to be able to run a Library with an entry point called by Mirage. That seems similar to the " Embedding/VM as a DLL" project proposed here: http://www.mirandabanda.org/cogblog/cog-projects/. Is this project active? The comment indicates this is mostly refactoring & repackaging. Anyone have a perspective on this?

Best regards

Joerg



Mirarge might be a good stepping stone, but ultimately I think we want Cog running directly on the Xen "hardware" without Mirage.  Erlang and Haskell are languages that already do this. [1]  We need to get on that list at the bottom.  

+1.  I am trying to get funding to do this, including modifying the execution model to provide excellent debugging facilities for promise-style concurrency (adding scheme-like continuation support to the VM, and allowing exception search to proceed from a promise to its creating context, etc).

Maybe a good starting place is SqueakNOS [2] since it is reported to work with Grub and there is PVGrub [3] [4]. 

I'm not sure.  Xen has a special segmented memory model so assuming, as the existing VMs do, a single contiguous heap is not a good match.  Spur on the other hand has good support for memory segmentation.  Further, one wants a high-performance VM, and Sista provides adaptive optimization potentially with no warmup time because one can save an optimized image).  

I should say that starting in February I am changing to half-time at Cadence.  Half of my time is therefore available for me to bootstrap a business around Pharo, Squeak and the Cog, Spur and Sista VMs.  If this is successful I hope to become independent full-time, or rather that I'm in a Snalltalk-centric company if which I'm a co-founder.  I'm working with specific people in the community and one thing we imagine is a company with close ties to Rmod.  It would be vry nice to grow a company where people completing their PhDs at Rmod had somewhere to go where they could continue working with Pharo instead of going to Google et al.  There us a clear need for companies around Pharo that can contract to provide technology services. Such a thing will take a while to ramp up, but the time is ripe.



--
best,
Eliot