Why a major revision? There are plenty of 64bit jvms out there, I imagine that the dalvik switch to 64bit would be a fairly straightforward engineering task. It would have to be done in any case.
As far as java code is concerned, an int is always 32 bits and and a long is always 64. It doesn't matter whether the jvm is 64/32.
Most JVMs are stack base, Dalvik in an other hand is register base with fixed width.
True, the VM itself would run faster once ported to ARMv8 in either AArch32 or AArch64 ISA, but without major revision of the DalvikVM, virtualized apps is still running in a 32 bit environment only.
It's true that as long as Dalvik only exposes 32-bit registers to programs, virtualized apps would still run in a 32-bit environment.
But they should still experience performance benefits as the VM handles the associations between bytecode and hardware instructions behind the scenes. In this case, a 64-bit Dalvik would run bytecode using the AArch64 ISA. The apps won't be able to take advantage of 64 bit registers, but as your Red Hat link shows, when all other factors are equal the performance delta between 32 bit and 64 bit builds of a program is quite small except in memory constrained situations.
It's true that as long as Dalvik only exposes 32-bit registers to programs, virtualized apps would still run in a 32-bit environment.
But they should still experience performance benefits as the VM handles the associations between bytecode and hardware instructions behind the scenes. In this case, a 64-bit Dalvik would run bytecode using the AArch64 ISA. The apps won't be able to take advantage of 64 bit registers, but as your Red Hat link shows, when all other factors are equal the performance delta between 32 bit and 64 bit builds of a program is quite small except in memory constrained situations.
DalvikVM is a 32 bit virtual computer (machine), while the VM can be ported on any platform, the virtualized machine always have the same 32 bit specs regarding is opcode and register, limiting apps on a virtualized 32 bit platform only.
To be clear, I agree DalvikVM and virtualized Apps should have some benefit from all the changes in the ARMv8 platform like any other apps. But apps developers for DalvikVM won't be able use AArch64 features explicitly.
DalvikVM is a 32 bit virtual computer (machine), while the VM can be ported on any platform, the virtualized machine always have the same 32 bit specs regarding is opcode and register, limiting apps on a virtualized 32 bit platform only.
To be clear, I agree DalvikVM and virtualized Apps should have some benefit from all the changes in the ARMv8 platform like any other apps. But Dalvik developers won't be able use AArch64 features explicitly.
I'm still not convinced that reworking DalvikVM for 64-bits is a monumental task. Perhaps even, the benefit might only be minimal...
(But I'll be the first to admit I don't know a lot about Dalvik :-) )
To be clear, I agree DalvikVM and virtualized Apps should have some benefit from all the changes in the ARMv8 platform like any other apps. But apps developers for DalvikVM won't be able use AArch64 features explicitly.
Agreed. But the point of virtualization is that, in most cases, the VM invokes architecture-specific features for you.
I'm still not convinced that reworking DalvikVM for 64-bits is a monumental task. Perhaps even, the benefit might only be minimal...
(But I'll be the first to admit I don't know a lot about Dalvik :-) )
I haven't said it's an impossible task, still a task no one as done yet and potentially have some major compatibility impact. I'm sure it will be done soon enough but I'm curious how they will implemented it.
Yes, this is more or less the same advantages native apps got when calling system API. I just didn't get why they are using a VM when it doesn't need cross-platform apps, VM apps can't beat native code on efficiency.
Yes, this is more or less the same advantages native apps got when calling system API. I just didn't get why they are using a VM when it doesn't need cross-platform apps, VM apps can't beat native code on efficiency.
I've seen reports of native being 20x faster (and higher) than Java on android.
You do realize that Java application code is completely independent of the processor architecture. As a developer there is nothing you need to do to support 64 bit. (Unless you have some very specific native interface code in your app, which is not very common)
All apps compile to machine independent java byte code.
Googles 64-bit Dalvik VM has the task at runtime to convert the byte code into 64-bit processor specific instructions.
Form latest reports 48% of android users are on the latest android JellyBean (4.1+) which was released in July 2012. I'm not sure what you mean by "so many years"
My Galaxy S4 is on 4.2.2, a firmware "update" appeared the other day but it wasn't to 4.3 which as far as I know is the "latest" version.
I updated my iPhone 4 to iOS 7, on the day of release and it's over three years old.
I've seen reports of native being 20x faster (and higher) than Java on android.
Speed is a very subjective matter and can be fixed with many subterfuge like Samsung has demonstrate with their overdriven benchmarks, I much prefer talking about efficiency. While I found 20x a bit high, I do tend to believe there is a big energy taxes using JVM than using native code.
“The comments made by Anand Chandrasekher, Qualcomm CMO, about 64-bit computing were inaccurate,” said a Qualcomm spokesperson in an email. “The mobile hardware and software ecosystem is already moving in the direction of 64-bit; and, the evolution to 64-bit brings desktop class capabilities and user experiences to mobile, as well as enabling mobile processors and software to run new classes of computing devices.”
Comments
Why a major revision? There are plenty of 64bit jvms out there, I imagine that the dalvik switch to 64bit would be a fairly straightforward engineering task. It would have to be done in any case.
As far as java code is concerned, an int is always 32 bits and and a long is always 64. It doesn't matter whether the jvm is 64/32.
Most JVMs are stack base, Dalvik in an other hand is register base with fixed width.
True, the VM itself would run faster once ported to ARMv8 in either AArch32 or AArch64 ISA, but without major revision of the DalvikVM, virtualized apps is still running in a 32 bit environment only.
It's true that as long as Dalvik only exposes 32-bit registers to programs, virtualized apps would still run in a 32-bit environment.
But they should still experience performance benefits as the VM handles the associations between bytecode and hardware instructions behind the scenes. In this case, a 64-bit Dalvik would run bytecode using the AArch64 ISA. The apps won't be able to take advantage of 64 bit registers, but as your Red Hat link shows, when all other factors are equal the performance delta between 32 bit and 64 bit builds of a program is quite small except in memory constrained situations.
It's true that as long as Dalvik only exposes 32-bit registers to programs, virtualized apps would still run in a 32-bit environment.
But they should still experience performance benefits as the VM handles the associations between bytecode and hardware instructions behind the scenes. In this case, a 64-bit Dalvik would run bytecode using the AArch64 ISA. The apps won't be able to take advantage of 64 bit registers, but as your Red Hat link shows, when all other factors are equal the performance delta between 32 bit and 64 bit builds of a program is quite small except in memory constrained situations.
DalvikVM is a 32 bit virtual computer (machine), while the VM can be ported on any platform, the virtualized machine always have the same 32 bit specs regarding is opcode and register, limiting apps on a virtualized 32 bit platform only.
To be clear, I agree DalvikVM and virtualized Apps should have some benefit from all the changes in the ARMv8 platform like any other apps. But apps developers for DalvikVM won't be able use AArch64 features explicitly.
DalvikVM is a 32 bit virtual computer (machine), while the VM can be ported on any platform, the virtualized machine always have the same 32 bit specs regarding is opcode and register, limiting apps on a virtualized 32 bit platform only.
To be clear, I agree DalvikVM and virtualized Apps should have some benefit from all the changes in the ARMv8 platform like any other apps. But Dalvik developers won't be able use AArch64 features explicitly.
I'm still not convinced that reworking DalvikVM for 64-bits is a monumental task. Perhaps even, the benefit might only be minimal...
(But I'll be the first to admit I don't know a lot about Dalvik :-) )
To be clear, I agree DalvikVM and virtualized Apps should have some benefit from all the changes in the ARMv8 platform like any other apps. But apps developers for DalvikVM won't be able use AArch64 features explicitly.
Agreed. But the point of virtualization is that, in most cases, the VM invokes architecture-specific features for you.
Here is an example of virtualized apps getting performance increases for free when the VM is ported to newer hardware: http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack#enable-intel-eas-ni-in-oracle-jvm. That report measures the performance of the same java app depending on whether the VM uses Intel's AES-NI instructions behind the scenes. The only difference between the two trials is whether AES-NI is enabled in BIOS.
I'm still not convinced that reworking DalvikVM for 64-bits is a monumental task. Perhaps even, the benefit might only be minimal...
(But I'll be the first to admit I don't know a lot about Dalvik :-) )
I haven't said it's an impossible task, still a task no one as done yet and potentially have some major compatibility impact. I'm sure it will be done soon enough but I'm curious how they will implemented it.
Agreed. But the point of virtualization is that, in most cases, the VM invokes architecture-specific features for you.
Here is an example of virtualized apps getting performance increases for free when the VM is ported to newer hardware: http://software.intel.com/en-us/articles/intel-aes-ni-performance-testing-on-linuxjava-stack#enable-intel-eas-ni-in-oracle-jvm. That report measures the performance of the same java app depending on whether the VM uses Intel's AES-NI instructions behind the scenes. The only difference between the two trials is whether AES-NI is enabled in BIOS.
Yes, this is more or less the same advantages native apps got when calling system API. I just didn't get why they are using a VM when it doesn't need cross-platform apps, VM apps can't beat native code on efficiency.
Yes, this is more or less the same advantages native apps got when calling system API. I just didn't get why they are using a VM when it doesn't need cross-platform apps, VM apps can't beat native code on efficiency.
I've seen reports of native being 20x faster (and higher) than Java on android.
You do realize that Java application code is completely independent of the processor architecture. As a developer there is nothing you need to do to support 64 bit. (Unless you have some very specific native interface code in your app, which is not very common)
All apps compile to machine independent java byte code.
Googles 64-bit Dalvik VM has the task at runtime to convert the byte code into 64-bit processor specific instructions.
Form latest reports 48% of android users are on the latest android JellyBean (4.1+) which was released in July 2012. I'm not sure what you mean by "so many years"
My Galaxy S4 is on 4.2.2, a firmware "update" appeared the other day but it wasn't to 4.3 which as far as I know is the "latest" version.
I updated my iPhone 4 to iOS 7, on the day of release and it's over three years old.
There is the difference.
I've seen reports of native being 20x faster (and higher) than Java on android.
Speed is a very subjective matter and can be fixed with many subterfuge like Samsung has demonstrate with their overdriven benchmarks, I much prefer talking about efficiency. While I found 20x a bit high, I do tend to believe there is a big energy taxes using JVM than using native code.
From Daring Fireball:
Agam Shah, reporting for IDG:
“The comments made by Anand Chandrasekher, Qualcomm CMO, about 64-bit computing were inaccurate,” said a Qualcomm spokesperson in an email. “The mobile hardware and software ecosystem is already moving in the direction of 64-bit; and, the evolution to 64-bit brings desktop class capabilities and user experiences to mobile, as well as enabling mobile processors and software to run new classes of computing devices.”
Qualcomm did not provide further comment.
http://daringfireball.net/linked/2013/10/08/qualcomm
Oh boy.