4 ms·

Does anyone have information on what is actually different about ART?

by scotth 13y ago

oscargrouch 13y ago
Its a new compiler and VM, written in C++ instead of the Dalvik C, and with a new runtime; It looks that it can compile to two banckends: one called "Quick" and other called "Portable" I think "Quick" is a complete home backed Jit, while "Portable" is LLVM based So probably (im guessing from fast source code study): This VM can JIT from bytecode to native while running (the Quick backend) and can run a already native payload using the LLVM backend.. The native payload probably will be very optimized since is AOT, and the Quick, since is JIT will probably have lower optimizations (as a runtime compiled code) (and we can assume that, the Dalvik VM is getting obsolete) Edit: adding more observations.. They have created a very sophisticated retargatable compiler that deliver into a SSA based IR and from there it goes to the backends that i have cited earlier
- devx 13y ago
  If it's LLVM, that pretty much opens the door for running Native Client apps on Android, and possibly even merging Android with ChromeOS, right?
  - oscargrouch 13y ago
    Thats a good guess.. theres a way to be sure of it.. The bitcode from Pnacl is different from the LLVM one.. But the "portable" backend naming scheme maybe could mean they will use the PNacl-LLVM instead of the pure LLVM one.. I wonder how Chrome could glue with this.. but if the Nacl/Pnacl uses the PPAPI api, in this hypotethical scenario they would replace the PPAPI runtime with a runtime compatible with ART.. it can be done, and the final c++ application source code would look like the java one.. edit: This could also mean the ndk applications will be first class citizens and wont need to rely on a java shim + native bindings.. I think that is more likely than the ChromeOS integration scenario
    - deleted 13y ago
      [deleted]
- kllrnohj 13y ago
  "quick" is also an AOT compiler like the LLVM-based "portable", not a JIT.
  - oscargrouch 13y ago
    Ok, so it's AOT.. but this is their own backend? (not the LLVM one?) and will have no JIT at all? If they troubled creating their own IR and are not reusing the LLVM one.. it probably means that the LLVM backend are only being used to retarget to the several architectures supported by it.. Otherwise it doesnt make much sense, since they are controlling the optimizing compiler in a custom way without the LLVM help in that matter Also, if we remember they use renderscript targeting the LLVM and, that the output could go directly to the graphic processors instead of the cpu, it make more sense to have this sort of design.. They work directly in the ABI and voila, everything just works and talk to each other despite its different roots (java, ndk, renderscript.. + ..put something else here..)

Does anyone have information on what is actually different about ART?

by scotth 13y ago

Does anyone have information on what is actually different about ART?

Its a new compiler and VM, written in C++ instead of the Dalvik C, and with a new runtime; It looks that it can compile to two banckends: one called "Quick" and other called "Portable" I think "Quick" is a complete home backed Jit, while "Portable" is LLVM based So probably (im guessing from fast source code study): This VM can JIT from bytecode to native while running (the Quick backend) and can run a already native payload using the LLVM backend.. The native payload probably will be very optimized since is AOT, and the Quick, since is JIT will probably have lower optimizations (as a runtime compiled code) (and we can assume that, the Dalvik VM is getting obsolete) Edit: adding more observations.. They have created a very sophisticated retargatable compiler that deliver into a SSA based IR and from there it goes to the backends that i have cited earlier

devx 13y ago
If it's LLVM, that pretty much opens the door for running Native Client apps on Android, and possibly even merging Android with ChromeOS, right?
- oscargrouch 13y ago
  Thats a good guess.. theres a way to be sure of it.. The bitcode from Pnacl is different from the LLVM one.. But the "portable" backend naming scheme maybe could mean they will use the PNacl-LLVM instead of the pure LLVM one.. I wonder how Chrome could glue with this.. but if the Nacl/Pnacl uses the PPAPI api, in this hypotethical scenario they would replace the PPAPI runtime with a runtime compatible with ART.. it can be done, and the final c++ application source code would look like the java one.. edit: This could also mean the ndk applications will be first class citizens and wont need to rely on a java shim + native bindings.. I think that is more likely than the ChromeOS integration scenario
  - deleted 13y ago
    [deleted]
kllrnohj 13y ago
"quick" is also an AOT compiler like the LLVM-based "portable", not a JIT.
- oscargrouch 13y ago
  Ok, so it's AOT.. but this is their own backend? (not the LLVM one?) and will have no JIT at all? If they troubled creating their own IR and are not reusing the LLVM one.. it probably means that the LLVM backend are only being used to retarget to the several architectures supported by it.. Otherwise it doesnt make much sense, since they are controlling the optimizing compiler in a custom way without the LLVM help in that matter Also, if we remember they use renderscript targeting the LLVM and, that the output could go directly to the graphic processors instead of the cpu, it make more sense to have this sort of design.. They work directly in the ABI and voila, everything just works and talk to each other despite its different roots (java, ndk, renderscript.. + ..put something else here..)