
The strange case of virtual machines on telephones - MaysonL
http://apenwarr.ca/log/?m=201008#26
======
bad_user
Straw man alert !

I have multiple arguments on why I prefer virtual machines (like the JVM), and
none of them is security ...

    
    
         - portability between hardware architectures
         - portability between operating systems (mostly)
         - memory management that doesn't suck
         - and yes, decent speed in return for a high-level programming language
    

Also, in time Java gained an extra advantage ... open-source libraries that
are fucking top-notch, in some cases with no replacement in the "native"
department.

Regarding Android versus iPhone ... that iPhone emulator doesn't run on
anything else other than OS X, or does it?

~~~
wmf
_memory management that doesn't suck_

You can have GC and AOT compilation, as the post says in a footnote.

 _decent speed in return for a high-level programming language_

High-level languages can be AOT compiled.

 _Java gained an extra advantage ... open-source libraries that are fucking
top-notch_

So maybe Android should have used Java, but compiled it direct to ARM rather
than burning users' cycles on an interpreter.

~~~
bad_user
> _So maybe Android should have used Java, but compiled it direct to ARM
> rather than burning users' cycles on an interpreter._

It doesn't have to be an interpreter, the processor itself can be optimized
for Java (or whatever bytecode you'd like), a point the article also missed.

This has been going on since 1996 ...
[http://bwrc.eecs.berkeley.edu/CIC/announce/1996/java-
procs.h...](http://bwrc.eecs.berkeley.edu/CIC/announce/1996/java-procs.html)
(and the concept itself was first tried with the Lisp machines I think).

The difference between high-end phone makers, like Apple, and the low-end
phone makers ... low-end phone makers cared and still care only about price,
not about how snappy those Java apps run.

Again ... the article sets up a straw man.

Desktop Java applications are slow and ugly, but show me an open-source IDE
that can compete with the breath and depth of Eclipse / IntelliJ IDEA and
their plugin ecosystem.

There's some merit to Java in that ... open-source developers would rather
spend their time working on the features they want, rather than hunting down
memory-leaks or deal with all the shit that cross-platform development brings.

~~~
astrange
> It doesn't have to be an interpreter, the processor itself can be optimized
> for Java (or whatever bytecode you'd like), a point the article also missed.

This is slower than compiling it to a more easily implemented ISA.

------
jacquesm
Funny, I think mobile phones are one of the few places where VMs actually make
a whole lot of sense, given that you'll need to keep your applications
compatible with whatever CPU happens to run generation 'X' of the phones out
there, today, and more importantly, in the future.

Like this manufacturers are not restricted by backwards compatibility. All
they have to do is guarantee that the VM will work as advertised and in a
compatible way.

All the apps are then automatically available for the new processor platform.

~~~
wmf
Yeah, those phones keep switching processors. They used to use ARM, but then
they switched to, uh...

Processor portability? YAGNI.

~~~
ergo98
[http://www.electricpig.co.uk/2010/05/05/intel-moorestown-
mee...](http://www.electricpig.co.uk/2010/05/05/intel-moorestown-meet-the-
power-behind-your-next-android-phone/)

Indeed.

~~~
wmf
I'll believe this when it actually ships. Also, there's a kind of karmic
justice to see Intel on the losing side of an instruction set monopoly.

------
rbanffy
There's a good reason for vms (like Java/Dalvik) on mobile phones: different
processors. Google can't make sure every Android device rubs on the same
processor and Dalvik bytecode runs unmodified regardless of what processor you
have in the device.

Native binaries work for Apple because all iThings use ARM and that won't
change anytime soon.

~~~
ojilles
The author claims this is not a legitimate reason: "Just ask any Mac
developer". I'm assuming here he means that compilers can solve this problem
for you (and hence don't incur a run time performance tax).

~~~
vetinari
It is actually a problem on Macs: there are entire libraries of applications,
that will never run on any new Mac. PPC/Classic is not supported, PPC/OSX may
or may not run, depending on the app. Forget 68K/Classic.

(Yeah, I should have bought PC versions of Lucasfilm games, not the Mac ones.)

~~~
jsnell
You can't run them on ScummVM?

~~~
rbanffy
And you just made the point for why use VMs ;-)

Wouldn't it be nice to have a ScummVM that can run not only games but real
applications?

------
kjetil
While its's tempting to pick minor nits in this post, the only appropriate
answer is this: So what?

For server-side web applications, VMs (and the JVM in particular) already won.
Sorry. They've made industrial strength GC, JIT and multi-threading features
for the mass market.

As for phones, I really doubt whether Android's use of a VM will have anything
to do with its success. There are many factors which will be much more
important, like fragmentation.

------
jrockway
Wow, I hate it when someone writes a scathing commentary on Java and I have to
say they are completely wrong.

 _Java is still much slower than native code, and you can see it clearly just
by looking at any app_

Let's see some numbers. Oh, here are some:

[http://shootout.alioth.debian.org/u32/benchmark.php?test=all...](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=javasteady&lang2=gpp)

2x difference. Yeah, it's slower, but do you really notice the difference
between 2ms and 1ms when your web page loads? Didn't think so.

With people regularly writing server-side apps that handle millions of users a
day in languages whose _benchmarks_ run 50x slower than C++, and those apps
working fine, it's not really a stretch to pick a language that runs 2x slower
than C++ on a device that doesn't even do anything computationally intensive.
("Received 'incoming call interrupt'. Display something pretty on the screen."
Guess what, not CPU intensive!)

~~~
potatolicious
> _" Yeah, it's slower, but do you really notice the difference between 2ms
> and 1ms when your web page loads? Didn't think so."_

But that's not what happens in real life. A 2x performance difference means
1000ms instead of 500ms to load a page - and _that_ is noticeable. It's also
the difference between 30 fps in a game vs. 15 fps - that is _really_
noticeable.

The list goes on. A 2x performance penalty is _huge_. For desktop
applications, our hardware is so ludicrously overpowered for what we do with
it that this penalty large doesn't matter (as you said, 1ms vs. 2ms), but in
mobile land, where hardware constraints are still very, very real, this is
absolutely a critical issue still.

Apple's platform is by far the most responsive out of all of the current
smartphones, and I think it'd be foolish to discount native code as one of the
primary factors in this. The responsiveness is also part of what attracts
users - people want their machines to work on _human_ time, not slower-than-
human time.

~~~
jrockway
_but in mobile land, where hardware constraints are still very, very real,
this is absolutely a critical issue still_

A machine with a 1Ghz processor, a half a gig of RAM, dedicated video
processing hardware, dedicated audio compression hardware (the GSM modem,
etc.), and so on is "constrainted".

The premise of the article is that's impossible to achieve reasonable
performance on a mobile device while using a virtual machine. This is
obviously false, as Android performs wonderfully on my phone. A call comes in,
the "slide to accept" action works smoothly. I visit a web page, it loads as
fast as the network can give it to me.

Apple's OS may be more responsive, but I'm not really sure about that. The
browser feels the same. Maps feels the same. Receiving a call feels the same.

We've passed the point where every bit of performance matters. Now, it's about
features -- let me know when I can use irc over ssh on the iPhone or use
Google Voice to make calls from the native Dialer application. "Slow" VM or
not, my Android phone can do that stuff, but the iPhone can't.

~~~
Qz
I've used iPhones and my HTC Incredible seems faster and more responsive.

~~~
jrockway
I haven't used an iPhone enough to really know for sure. But the premise that
"using a VM will make it impossible to have a usable phone" is obviously
false.

------
kevinpet
I stopped reading as soon as he trotted out the "JVM is slow" line. If you
still believe this, you are ignoring reality or arguing from something some
guy told you ten years ago.

Yes, you can argue that in some cases, you can get about a 2x speedup with
native code, or more by using hardware features not exposed in java (stream
processing), but that's not relevant to the argument this guy appears to be
making.

~~~
jrockway
Yeah, but I tried opening Eclipse and it took a while for my 3400 RPM disk to
read it into memory. Since Eclipse is written in Java, Java is slow!

Incidentally, Visual Studio and KDevelop are native code, and they take a
while to load too. Could it be that big bloated apps are big and bloated, VM
or not?

~~~
blub
Not only Eclipse is slow, but pretty much every Java program that I've tried.
Also, a lot of code in Visual Studio is managed, especially in the UI.

------
bconway
Lots of straw men, lots of flawed premises. Google didn't choose Java because
of VM security, they chose it because everyone on the planet knows it. Can the
same be said for Objective-C?

 _But every step of the way, they're going to have this giant anchor of
[UniConf] Dalvik tied around their neck, and Apple won't_

Kinda like... Objective-C and a limited library?

~~~
bruceboughton
It's not clear that Objective-C is hampering developer uptake of the App
Store.

------
gvb
Links to UniConf:

* <http://alumnit.ca/wiki/index.php?page=UniConf>

* <http://alumnit.ca/wiki/attachments/uniconf.pdf>

------
moron4hire
I always thought Java's slowness is due to the scads of layers of abstraction
you have to go through to get anything done. You can't do anything without
hitting a mile of stack trace.

------
teyc
The author is clearly correct and yet he is wrong because he asked the wrong
question.

How fast it runs is not as important as "is it fast enough for the customer"
and "will I be able to produce this at a reasonable price?"

Everything in engineering is a trade-off.

A VM in a puny chip is the price one pays for a developer audience, to build a
thriving ecosystem of apps so that consumers will want to buy the device.

~~~
lkosewsk
_A VM in a puny chip is the price one pays for a developer audience, to build
a thriving ecosystem of apps so that consumers will want to buy the device._

Too bad Apple didn't pay that price, because otherwise, they might have had
consumers and a thriving... oh, wait...

~~~
teyc
Apple already had a toolchain and developers before iPod Touch arrived. It
made sense for them.

A newcomer with no audience does not have too many choices. The world simply
has more developers who program to JVM or CLR.

------
ergo98
The author completely devastates their core point when they say-

"Now I've told you why Android's use of a Java-like VM was demonstrably wrong
(Apple demonstrated it) from the beginning"

What was demonstrated, the author claims, was that Android chose "Java" for
security, where the iPhone demonstrates that native can be secure.

But...Android didn't choose Java for security. You have the full ability to
use native code in your apps, courtesy of the NDK, and of course Android runs
apps in an isolated process (using the inherent security functionality of
Linux). Apps can't stomp on the system or walk outside of the lines and
allowances granted them, Dalvik engine or not.

While you still need a Java main, you can build almost all of your app in the
NDK if you really want to. But being pragmatic, 99% of most apps are comprised
of a light veneer over the SDK (itself usually high-performance native), and
in such cases native or not makes absolutely no practical difference. Where
you need to go native for specific cases, go native.

So why, then, does Android use Dalvik? Probably because they intend for the
platform to be usable on a heterogeneous array of platforms -- you can run
Android on your PC, for instance, and upcoming smartphones may feature the
Intel Moorsetown x86 mobile processor. By encouraging Dalvik, the platform,
specifically the application portfolio, is freed from being tied to a specific
processor architecture. The author tries to diffuse this obvious advantage by
saying that such a change is "just a recompile away", but that is simply
absurd -- when the first Moorestown phone comes out, off the bat it will be
able to run the majority of market apps with no change at all, including those
that used the NDK (as the Android norm is to conditionally load native
modules, using a managed fallback if it isn't appropriate).

This is all ignoring that Android has a far more granular, and I would say
robust, security system than the iPhone: recall that the iPhone is where
someone got an app that ostensibly was a "flashlight" app, but in actuality
was a tethering app, which absolutely _demolishes_ any illusions that the
review process is any sort of security check. But that isn't necessarily a
part of the managed/unmanaged argument (because it has been shown that is a
misdirection to begin with).

~~~
Tichy
I thought the NDK just interfaces to the Android Java API, so there would
still be a lot of Java code in your app?

~~~
ergo98
The primary API was provided in Java, so yes from the NDK for many needs you
have to step back to Java-world momentarily. This is a simply a limit of time
however (given that Dalvik was their primary app runtime for other reasons) --
Google has been pushing more and more functionality directly to the NDK (e.g.
2.2 gives you the ability to fully use OpenGL from native code).

However that is neither here nor there. You have the full ability to fall to
native, to go hog wild with memory references and uninitialized pointers and
stack overflows and trying to break free of the box you are placed within (the
process boundaries). You have the ability to include C code from other
projects for codecs and processing, etc.

