<br><br><div class="gmail_quote">2009/10/22 Göran Krampe <span dir="ltr"><<a href="mailto:goran@krampe.se">goran@krampe.se</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hi all!<br>
<br>
Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I need to at least hurry up and get the StackInterpreter released.<br>
</blockquote>
<br>
Which of course tickles me enough to ask again about your status? :)<br></blockquote><div><br></div><div>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 :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Let me indulge in some "braindumping" here about Squeak vs Android:<br>
<br>
Android is coming on a broad front right now and I am interested in how Squeak can "fit" into that platform.<br>
<br>
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.<br>
<br>
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)".<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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. :)<br>
<br>
There is no JIT. It is not fast. BUT... it is the VM on the Android and it comes with tons of libraries etc.<br>
<br>
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...<br></blockquote><div><br></div><div>But a JIT can live in a library. Provided one can allocate executable memory (see my concluding question below).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">So in order to be able to write anything remotely interesting for an Android one needs to go "through" Dalvik somehow.<br>
<br>
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.<br>
<br>
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?<br>
<br>
I am probably talking totally "out of my hat". Would be really interesting to hear thoughts from Eliot on all this.<br>
<br>
Anyway, getting Squeak running on Android in any fashion would be awesomely interesting :) - it IS coming, all over.<br></blockquote><div><br></div><div>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.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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...<br>
<br>
regards, Göran<br>
<br>
PS. This article + comments (by Dan Bernstein also, creator of Dalvik) is a bit interesting.<br></blockquote><div><br></div><div>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.</div>
<div><br></div></div><br>