Squeak + Android and Dalvik!? (was Re: [Vm-dev] Performance, Quality and Process [was Array new: SmallInteger maxVal])

[Eliot Miranda]

2009/10/22 Göran Krampe <goran at krampe.se>

>
> Hi all!
>
> Eliot Miranda wrote:
>
>> I need to at least hurry up and get the StackInterpreter released.
>>
>
> Which of course tickles me enough to ask again about your status? :)
>

The V1 JIT has been released to customers, and so is now our only VM, in use
in the server and client components.  Performance is around 2.5x to 3x the
old VM for real world use (number of clients that can connect to a server).
 Certain macro benchmarks are in the 4x to 5x range.  We have been very busy
and so the process of getting the VMs released has been put on the back
burner.  I need to move them to the front of the stove :)

Let me indulge in some "braindumping" here about Squeak vs Android:
>
> Android is coming on a broad front right now and I am interested in how
> Squeak can "fit" into that platform.
>
> Unless you have been living under a rock (or working hard on a JIT we all
> want!) the mobile industry is heating up a LOT. Android is really impressive
> and is getting thrown on all sorts of interesting hardware, not only phones.
> I think that it really will be disruptive in a way that IPhone can never be
> since it is a "high end only" product from a single hardware company.
>
> The Android SDK/dev stack is interesting, it is a Linux kernel etc, has the
> Dalvik VM which is a VM with its own bytecode set that is designed for
> phones and "runs Java". It does it by using a cross compiler from java
> .class files to so called "dex" files and then runs those. So it is not a
> "Java VM (tm)".
>
> It is actually *register based* and I have peeked at its sources. It seems
> to have been written with a "brute force" approach by C-coders - nothing
> wrong in that of course.
>

Much is made of register-based vs stack-based bytecode designs.  IMO, it
makes little difference to overall performance since there are
straight-forward techniques for transfrming stack bytecode into
register-based code.  e.g. the VisualWorks VM does this, and Ian Piumarta's
thesis describes essentially the same technique.  For languages like
Smalltalk with extremely high send frequencies there is little scope for
caching results in registers.  The important thing is to have a
register-based calling convention.

David Simmons' performance work also demonstrates that stack bytecodes arte
no hinderance to performance.  He focusses much more on inline cacheing
performance and allocation and reclamation speed (GC), and gets excellent
speed.

First they wrote a simple interpreter core in a single C function. Then they
> split it up using macros etc in order to be able to implement each bytecode
> in assembler for each major CPU. The "old" C-only interpreter is still there
> and it basically is a "while (!) { FETCH; switch (bytecode)
> for-each-bytecode}"-loop. :)
>
> There is no JIT. It is not fast. BUT... it is the VM on the Android and it
> comes with tons of libraries etc.
>
> Now... there is also an NDK (Native SDK) that allows one to compile C to
> libraries (but not executables, not sure) that can in turn be used from
> java/Dalvik... humm...
>

But a JIT can live in a library.  Provided one can allocate executable
memory (see my concluding question below).


> So in order to be able to write anything remotely interesting for an
> Android one needs to go "through" Dalvik somehow.
>
> My silly first "funny idea" was to somehow marry the Squeak VM with the
> Dalvik VM. Merge the sources and somehow make it possibly to "drive" the
> Dalvik interpreter by feeding it "dex" bytecodes from Squeak. Sure, this
> will only work on a "rooted phone" I presume, but anyway, would be cool.
>
> If we could do that I guess one could open a VNC connection into the Squeak
> VM (if we can get Sockets to work) running inside the Android
> simulator/device and then using Squeak producing dex bytecodes one could
> perhaps dynamically "drive" Dalvik?
>
> I am probably talking totally "out of my hat". Would be really interesting
> to hear thoughts from Eliot on all this.
>
> Anyway, getting Squeak running on Android in any fashion would be awesomely
> interesting :) - it IS coming, all over.
>

The devil is in the details.  I'm pretty sure that Squeak would run horribly
above Dalvik (sends, GC, tagged integers are all likely to suck on a VM not
designed for Smalltalk).  But if Dalvik is not the entirte framework (you
speak about libraries above) then running alongside is perhaps a
possibility.  e.g. this is how David Simmons' S# runs within .net.


Sidenote: Getting Squeak to run on Maemo (Nokia's Linux based OS for n900
> etc) and derivatives of Maemo is probably tons of less work (because it is
> not a java centric thing and has much more standard Linux stuff) - but tons
> of less interesting given the market...
>
> regards, Göran
>
> PS. This article + comments (by Dan Bernstein also, creator of Dalvik) is a
> bit interesting.
>

Is there no access other than through the VM?  One of the major pains with
the iPhone is the lack of support for JITs.  The mmap function prevents
granting execute access on the memory it allocates.  John McIntosh has
suggested that Apple might be persuaded to provide a work-around for certain
applications (i.e. the Cog JIT) but I think John is merely speculating
optimistically (John, am I right or is there a real possibility here?).  It
would be great if Android didn't present simular hurdles.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20091022/c2e0b9f2/attachment.htm