> -----Original Message-----
> From: Pharo-dev [mailto:[email protected]] On Behalf Of
> Alain Rastoul
> Sent: Tuesday, January 13, 2015 11:10 PM
> To: [email protected]
> Subject: Re: [Pharo-dev] Hosting the Pharo VM on MirageOS
> 
> Le 14/01/2015 04:39, Joerg Beekmann, DeepCove Labs a écrit :
> > 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-system
> > s-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
> >
> >
> >
> >
> >
> 
> Hi,
> 
> I've been thinking on that kind of question from a different point of
> view: cutting an application
> in parts, and running several single core pharo vm in different xen vms with
> inter domain communication (or network communication if clustered on
> different hosts) in order to achieve multi core processing.
> For ipc communication, I found libvchan , whose documentation seems to be
> only the xen source code and a small sample in the code, and the vicent
> bernadoff open mirage post (no a lot of doc) and I also found  xen sockect, an
> older paper here
> http://www.researchgate.net/publication/221461399_XenSocket_A_High-
> Throughput_Interdomain_Transport_for_Virtual_Machine/links/00b7d51cb10e
> c74e9b000000.pdf
> that look interesting because it has the same api as sockets, but no more
> information, it seems to be only an old research paper.
> Forthe last one, it  has been be done on top of grant table and could 
> probably be
> written  but I guess not trivial at all.

For an example of some work being done in this area by the mirage group see: 
http://openmirage.org/blog/update-on-vchan.
They seem to have come some way with this. Here is the bottom line. I've seen 
no sign of the next post.
    "vchan is a very low-level communication mechanism, and so our next post on 
this topic will address
    how to use it in combination with a name resolver to intelligently map 
connection requests to use vchan
     if available, and otherwise fall back to normal TCP or TCP+TLS."

> About openmirage, since the unikernel has to deal with code dependencies,
> how to integrate the dependency analyser with smalltalk code in order to build
> a specialized vm ?
I was not planning specializing the VM for the image. But rather link in a VM 
with everything needed to run
a range of images. The dependencies are handled by creating an OCAML module 
that expresses these and the
VM code then lives in the module. The OCAML dependence analyser (a sat solver) 
then ensures those are satisfied.

> And about your idea of running the vm in a dll, how will it manage primitives 
> in
> specialized libraries ?
That I don't know. Probably pick a reasonable set of default primitives. I'll 
note the idea of the VM as a dll was not 
mine but rather seemed to be a proposed project on Eliot's Cog Blog.

> I suppose you would also have to go into the dependency toolchain to describe
> pharo packages dependencies in terms of openmirage functionality
> dependencies ?
> 
> May be you could also look at Android port of pharo, since it runs the vm as 
> a jni
> dll ?
I will thanks!

> But the primitive part of android port (libraries) do not have to deal with
> dependencies since android is based on linux.
Mirage is also Linux in a sense. It You can run Mirage applications as user 
executable on Linux. That is how they are typically debugged. The cool idea is 
to then say 
"lets perform whole system dependency analysis and build a Kernel with only 
what our application needs".
> 
> --
> Regards,
> 
> Alain
> 
Hi Alain



Reply via email to