Menu Sign In Contact FAQ
Welcome to our forums

Have tablets reached the end of the road for performance?

ESKC (Uppsala/Sundbro), Sweden

Peter wrote:

I have never programmed in Java but surely an app which is supposed to run in a Java VM cannot compile to native code, because that defeats the whole point of Java.

Of course it can compile to native code, and of course it doesn’t defeat the whole point of Java (and some of the earliest JVMs, e.g. the one from Sun, could JIT compile). The whole point of Java is ‘write once run anywhere’ and transforming the byte code to native instructions at run-time doesn’t break that at all. The JVM isn’t an interpreter as such, it’s a virtual machine and JVM instructions are a lot closer to machine instructions than the English-like statements in an interpreted language. All Java code is compiled to this byte code before it will run and it’s not a huge step to then convert the byte code to machine instructions for whatever processor the JVM is running on. As far as the Java source code is concerned, it’s a compiled language just like C++. There’s a whole bunch of languages that have compilers for the JVM, e.g. Clojure, Kotlin etc. (and even some surprising languages – there is a COBOL compiler which targets the JVM). The point of the JVM is you have a hardware and OS agnostic virtual machine architecture you can target (the ‘run anywhere’ bit). The hardware agnostic part breaks down a bit when you get to specialised platforms though like mobile which has a bunch of hardware other JVMs don’t know about (and vice versa). There’s other things the JVM gives you like the ability to choose between garbage collectors, so you can easily change how memory is managed without having to modify a single line of code.

There were even CPUs that would natively run Java bytecode instructions, but they never really took off – there was no point, as JIT compilation was already a thing by then.

Even browsers will often JIT compile Javascript (don’t confuse Javascript with Java – how Netscape never got sued back in the day by Sun I don’t know – but Javascript has nothing to do with Java), and Javascript was designed as a purely interpreted language.

There are also languages that compile to Javascript (transpile) which fills my inner assembly language programmer with a sense of profound horror and revulsion but there you go!

Last Edited by alioth at 29 May 09:42
Andreas IOM

Peter wrote:

Interesting… I didn’t know that android can run native code. I recently spoke to one app developer who told me that android’s inability to do this is why the IOS version of his app runs a lot faster (and it does).

The java JVM is basically a fairly simple virtual processor with a simple stack (no registers), AFAIK this approach was chosen so it would work with the x86 which has few registers to begin with (even though Sun’s SPARC had loads). So all java code is compiled to fit this virtual processor with simple 8 bit operands, it is thus not a huge challenge to further compile the virtual machine instructions to one better suited to the chips architecture at runtime, this secondary stage has been around in various guises since nearly the beginning of the language. So for simple operands, where you load, modify and store something it is very fast, no real difference to say C.

However with some exceptions all of the APIs are virtual, and designed to suit the lowest common denominator. This is most obvious when working with graphics hardware, where these abstractions are implemented in substantially different ways, hence the performance differences.

IMHO in a power constrained device, efficiency, the better use of a GPU, and better APIs that use the hardware more effectively are the key to a better experience than a faster CPU, as the latter just leads to ever bigger battery requirements.

Last Edited by Ted at 29 May 13:52

Many thanks for the explanation (both above).

Shoreham EGKA, United Kingdom

In my experience with the ADLConnect app the iOS app is faster probably because of better libraries and more efficient memory structures. Java does not support pointers so often huge data strutures have to be copied, rebuild etc. while in raw C much more efficient pointer based solutions can be used. But this is at the same time a design feature of Java which sacrifices a bit of efficiency for less error prone code. In C if I want to cache a data structure to the flash memory for faster app starts in the future I can just copy the whole area from memory at once. As far as I know therre is no way to do anything similar in Java.

Sebastian_G wrote:

Java does not support pointers

Java most certainly has pointers, however you can not control them directly, no pointer arithmetic etc and they don’t call them pointers even thought they are :-) Java can create a cache, like your example. But your cache may move from time to time. (unlikely if you create it at the beginning) This is where it would struggle for example in a real time programming scenario, say if you tried to use it in flight control, perhaps your cache needed to move pausing your thread at a crucial moment… trying to keep this sort of flying related :-)

Last Edited by Ted at 31 May 21:48

Sebastian_G wrote:

Java does not support pointers so often huge data strutures have to be copied

That’s completely incorrect. Java most definitely uses pointers, and all the time. Structures (instances) are passed by reference, not by value, so contrary to what you say – huge structures are only ever copied if you explicitly write code to copy them. Otherwise, everything is passed only by reference (in other words, to a C programmer, that means using a pointer).

For instance, in Java if you wrote:

BigThing foo=new BigThing();
BigThing bar=foo;

then bar is not a copy of foo, both foo and bar are the same actual instance in memory. What ‘foo’ and ‘bar’ are in the above examples is nothing but a 32 (or 64 bit) memory address, and the “=” operator is doing nothing but copying a 32 (or 64 bit) address. The confusion may arise because if you did that in C or C++, then bar would be a new copy of foo (on the stack), not a pointer to foo.

The above in Java is effectively like doing this in C:

BigThing *foo=(BigThing *)malloc(sizeof(BigThing));
BigThing *bar=foo;

Similarly, when you call a method in Java passing some instance of an object, you’re not copying the object – you’re actually passing a reference (in other words a pointer) to the object.

For instance, a method:

public void doSomething(BigThing foo) {

in Java, effectively would be like this in C:

void doSomething(BigThing *foo) {


If you want to actually copy a large structure in Java rather than just a reference (i.e. a pointer) you must explicitly make a copy of the object.

As mentioned above you don’t have pointer arithmetic in Java, but generally it’s not going to make that much difference in terms of speed, especially when a lot of the time many programs are using data that’s not just a flat array in memory, but in collections such as hash maps. The main point it’s incorrect to say Java doesn’t support pointers (references), it’s actually more correct to say that Java doesn’t support not using pointers!

Last Edited by alioth at 02 Jun 17:18
Andreas IOM

alioth wrote:

The main point it’s incorrect to say Java doesn’t support pointers (references), it’s actually more correct to say that Java doesn’t support not using pointers!

The most correct thing to say is that there is no pointer datatype in Java, but that pointers are most certainly used in the implementation.

ESKC (Uppsala/Sundbro), Sweden

You cannot beat assembler, is what I say!

Then there is no debate because everybody knows exactly what is what.

fred: db “this is a string”, 00h

ld hl, fred

loads hl with the address of the string, not the string itself

Shoreham EGKA, United Kingdom
19 Posts
Sign in to add your message

Back to Top