From what I can gather, it seems FlexyCore generates more efficient, architecture specific assembly code at build time. This is where the performance gains come from.
A little deeper reading shows that it does this through the Dalvik VM, the VM on all Android devices.
The emulator is also one of Android's longstanding problems, and it would be nice if they fixed that once and for all, too.
I'm also hoping that with the arrival of powerful ARMv8 hardware in the couple of years, maybe they'll make their SDK for ARM, too, so it doesn't even need to be emulated in x86.
This feels like an "acquhire." I haven't yet seen a performance booster get any traction with OEMs. This sounds more-promising than Myriad's idea of replacing the whole VM with their Java VM.
Optimization in a battery powered device is tricky. After the initial work on Android's interesting JIT strategy, I have not heard much else about boosting performance. Developers who run into performance limits are stuck "doing it by hand" with native code and Renderscript. Maybe this signals a revival of interest in extracting better performance from Android's runtime environment.
Since Windows Phone 8, Microsoft also went fully native, by pre-compiling MSIL to native code on the Windows Store servers. The devices only have a linker to perform the last step of replacing the symbols by effective addresses on load.
Everything being native isn't always a better way. Android's architecture keeps code small, makes sure nobody eats the global heap, shares common bytecode (really, anything) pages across processes, and provides memory-conserving modularity tools within each VM instance's heap. It's a pretty elegant system and the reason there hasn't been a lot of new work on the JIT may be that the JIT is as good as it can be without eating more battery.
> Android's architecture keeps code small, makes sure nobody eats the global heap, shares common bytecode (really, anything) pages across processes, and provides memory-conserving modularity tools within each VM instance's heap.
Global heap can be controlled by process in many OS, nothing special about VMs.
Sharing of code pages between processes has been done in mainstream OS since a few decades.
Memory-conserving modularity tools, whatever that might be, aren't VM specific.
The only issue you are right about, is that bytecode is much more compact than native code.
> ... the reason there hasn't been a lot of new work on the JIT may be that the JIT is as good as it can be without eating more battery.
The current JIT is good enough for developers writing CRUD applications, HTML wrappers or the "fart app" of the month.
Those of us that care about performance use the NDK anyway.
> Those of us that care about performance use the NDK anyway.
If you had said "People porting game engines implemented in C use the NDK anyway" you might be right, and they do that because re-coding the game engine is impractical, not for performance. But the implementation of large systems in Android is best done in Java, for reasons of performance, modularity, and power efficiency.
Managed language systems exist for a reason. Dalvik bytecode is much more space efficient than native code, and Google has claimed it is about 2x as space efficient as Java bytecode, and 2x faster to interpret. Those factors reduce the need for a JIT in Android, and, until Android 2.3, Android didn't have one, and there were plenty of ambitious, performance-sensitive Android apps.
The Android component architecture enables a kind of code swapping that enables large apps to fit in a single process with a limited heap size. If you are not making use of component objects, you are not being memory efficient.
Android's Zygote and the use of copy-on-write goes beyond sharing pages of "pure" code. Any page can be shared between processes this way. This keeps global memory use down and makes it efficeint to start many more processes that would otherwise be practical with a VM language.
The Android base classes, Java toolchain, and runtime are the most sophisticated and efficient managed language environment for mobile devices. Ignoring them and going straight to NDK code without a specific performance case based on measurements of Android Java code performance, the effects of the JIT, and code size is a waste of time and a source of bugs that will be harder to find and fix.
Sorry, but your comment reads out as Google PR about Dalvik. Even with your published books I am not buying it.
The only thing you are right about is that bytecode is more space efficient than native code.
Everything else is easily done in native code as well, it is just a matter of the OS providing support for it, there is nothing special about having to be a VM.