I don't know, but remember that Android does not run the JVM, it runs the now deprecated Dalvik or the more modern ART, both Google in house projects.

None of them have all those million engineer hours baked in, not even close.

My guess is that the CLR have more man hours spent on than both those two implementations combined.

This is no longer true.

http://arstechnica.com/tech-policy/2016/01/android-n-switche...

It is my understanding Android simply uses the class library of OpenJDK. Android will continue to used the ART VM instead of the HotSpot VM.

True, but I personally believe this is the first step to adoption. The whole issue was around licensing..not because the Hotspot vm had something fundamentally missing (zygote and MVM notwithstanding)

That's hard to know and I have no insider knowledge.

From the outside it seems like a lot of work. Firstly HotStop is not optimized for fast startup, small footprint or short GC pauses. There is talk about merging the Java ME VMs but such things usually take years. Secondly Google built many proprietary extensions, eg DEX. I'm not sure that ART can even execute Java bytecodes.

Generally when referring to the JVM's performance people are talking about IBM J9, Azul Zing, HotSpot, etc, while Android has its own VM.

Additionally, most high-performance JVMs are optimized for long-running server applications, wile the CLR is optimized more for desktop applications (considerably better startup time, is fast without requiring lots of warmup, but doesn't do some of the very advanced optimizations JVMs tend to do). I suspect it would be easier to make the CLR performant on mobile than to make a JVM fast with constrained memory.

So basically, the CLR is probably already competitive on mobile devices. Does anyone know if Windows Phone uses a stock CLR or if they reimplemented it? Seems pretty snappy.

HotSpot at least doesn't have terrible startup time. 50msec for Hello World and about 500msec to get a JavaFX window on the screen with a button in it.

The .NET CLR isn't really "fast without requiring lots of warmup". It's a much simpler design that out of the box simply compiles each method the first time it's used. It doesn't "warm up" because it doesn't do profile guided or speculative optimisations at all. The weakness of the CLR is one reason C# pushes more optimisation complexity onto the developer e.g. having to mark virtual methods explicitly instead of methods being virtual by default. With respect to memory usage I guess it's not much different.

There are JVMs designed for old candybar feature phones (J2ME etc). The issue is not "can you make a mobile JVM" as the answer is clearly yes for any type of phone, even very old ones. The issue is "how much fancy technology can you fit in that space".

> With respect to memory usage I guess it's not much different.

Memory use is quite different due to reified generics and value types.

Oh, I'm not saying JVMs can't work on tiny devices (heck, there are JVMs on everything from 2005 feature phones to Intel ME to some random tiny SuperH chip in a car), just that a high-performance JVM has so far not been designed for that particular use case.

Windows Phone doesn't use the CLR at all.

.NET is AOT compiled to native code using the same backend (C2) as Visual C++.

CoreCLR, the same used in .NET Core

it's happening: CoreRT[0], a .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying .NET Native compiler toolchain. will enable you to compile for any OS/any platform including ARM. compile for every platform, run the AOT compiled Tree-shaken Machine code executable.

[0] https://github.com/dotnet/corert