4 ms·

it grates against my engineering soul when so many of my fellow engineers forget that the x86's themselves are virtual machines, microcoded architectures that i

it grates against my engineering soul when so many of my fellow engineers forget that the x86's themselves are virtual machines, microcoded architectures that implement x86's. And that any OS's job upon booting is to present a new virtual machine to the user--which is why the same box can be booted as a Windows machine, a unix machine, or a Macintosh--and so to add some additional code to simultaneously present additional virtual machine abstractions is not bad engineering, it's the very stuff of engineering. Abstractions are an efficient way to reduce the complexity of complex problems, and a virtual machine that allows the same code to run on top of different architectures can't be said to be "unnecessary".

vegabook 11y ago
There is no need for the JVM abstraction anymore, since the multiple architectures of the 90s such as Sun SPARC, SGI, Mips, PowerPC, X86, DEC Alpha, AS/400, have been pared back basically to two. Moreover, the more modern abstraction is the LLVM, which is targeted at the right level - compiler writers - without saddling the programmers and users with a bloated code translation layer that they must cart around everywhere they go. The JVM does nothing for a programmer, abstraction wise, that makes Java easier than, for example, Golang.
- tadfisher 11y ago
  Well, Android also supports MIPS, so there's three. Then there are the 64-bit variants, making six. Then there are the various levels of ARM compatibility and extension instruction sets, like Thumb-1 and Thumb-2. Android supports two broad sets of 32-bit ARM platforms, so in total you have seven target ABIs [1]. All of which I'm sure LLVM makes completely transparent to the developer and ekes out the same level of performance as an on-device JIT. Note that the preceding sentence was sarcasm. In reality, the VM mostly does not exist on Android beyond what's needed for a compatible runtime. The ART compiler emits machine code [2], or with the latest iteration, mostly machine code with stubs for JIT targets. Said code is in ELF binary format. [1] http://developer.android.com/ndk/guides/abis.html http://developer.android.com/ndk/guides/abis.html [2] https://source.android.com/devices/tech/dalvik/#features https://source.android.com/devices/tech/dalvik/#features
  - deleted 11y ago
    [deleted]
  - vegabook 11y ago
    "ekes out", that's rich. After taxing your native performance at least 50%, it's now eeking out performance. Haha.
    - tadfisher 11y ago
      50% over... C? That's quite respectable for a fully-managed OO language. Go can't even get close to that for the non-assembly-implemented parts of the standard lib. The synthetic benchmarks on ART agree with you, BTW. At that level of performance, your primary hits are I/O and UI, and that's not something a faster language target is going to improve. If you are writing tight loops for, say, scientific number-crunching, you should be writing assembly or doing GPGPU anyway. In the real world, with real applications, Java is not the bottleneck on Android; bad programmers and bad APIs are. Swift is pretty cool though.
      - vegabook 11y ago
        I meant to be somewhat flippant. "Sarcastic..." You have made some good points, tadfisher, especially with respect to the ARM architectures being fragmented, and the ART compiler. I take those points, and indeed, I do respect the JVM because it is an awesome piece of engineering to be giving up very little for the consistent target it provides. And let's be fair, Java and Scala are not slow languages. I have more of a philosophical problem with the JVM on the desktop and server ecosystems as these don't really need it anymore - arguably - and also, you have to admit that JVM languages still force you down an OO route which is not always very elegant. Even Clojure (apparently) needs to breathe in some ugly OO syntax if you want to touch the (admittedly huge) Java ecosystem. Look I use JVM tech: Cassandra in particular, am very impressed with it (I also code in Java to the Bloomberg API - less impressed with that). I don't love the JVM as you've gathered, for purist reasons and the fact that it takes me into a slightly dull corporate sort of culture, but I know that it has advantages. Anyway fun sparring with you. good points.
      - 11y ago
- brashrat 11y ago
  the JVM abstraction isolates foreign java code into a sandbox. I don't want outside code running native on my machine.

vegabook 11y ago

There is no need for the JVM abstraction anymore, since the multiple architectures of the 90s such as Sun SPARC, SGI, Mips, PowerPC, X86, DEC Alpha, AS/400, have been pared back basically to two. Moreover, the more modern abstraction is the LLVM, which is targeted at the right level - compiler writers - without saddling the programmers and users with a bloated code translation layer that they must cart around everywhere they go. The JVM does nothing for a programmer, abstraction wise, that makes Java easier than, for example, Golang.

tadfisher 11y ago
Well, Android also supports MIPS, so there's three. Then there are the 64-bit variants, making six. Then there are the various levels of ARM compatibility and extension instruction sets, like Thumb-1 and Thumb-2. Android supports two broad sets of 32-bit ARM platforms, so in total you have seven target ABIs [1]. All of which I'm sure LLVM makes completely transparent to the developer and ekes out the same level of performance as an on-device JIT. Note that the preceding sentence was sarcasm. In reality, the VM mostly does not exist on Android beyond what's needed for a compatible runtime. The ART compiler emits machine code [2], or with the latest iteration, mostly machine code with stubs for JIT targets. Said code is in ELF binary format. [1] http://developer.android.com/ndk/guides/abis.html http://developer.android.com/ndk/guides/abis.html [2] https://source.android.com/devices/tech/dalvik/#features https://source.android.com/devices/tech/dalvik/#features
- deleted 11y ago
  [deleted]
- vegabook 11y ago
  "ekes out", that's rich. After taxing your native performance at least 50%, it's now eeking out performance. Haha.
  - tadfisher 11y ago
    50% over... C? That's quite respectable for a fully-managed OO language. Go can't even get close to that for the non-assembly-implemented parts of the standard lib. The synthetic benchmarks on ART agree with you, BTW. At that level of performance, your primary hits are I/O and UI, and that's not something a faster language target is going to improve. If you are writing tight loops for, say, scientific number-crunching, you should be writing assembly or doing GPGPU anyway. In the real world, with real applications, Java is not the bottleneck on Android; bad programmers and bad APIs are. Swift is pretty cool though.
    - vegabook 11y ago
      I meant to be somewhat flippant. "Sarcastic..." You have made some good points, tadfisher, especially with respect to the ARM architectures being fragmented, and the ART compiler. I take those points, and indeed, I do respect the JVM because it is an awesome piece of engineering to be giving up very little for the consistent target it provides. And let's be fair, Java and Scala are not slow languages. I have more of a philosophical problem with the JVM on the desktop and server ecosystems as these don't really need it anymore - arguably - and also, you have to admit that JVM languages still force you down an OO route which is not always very elegant. Even Clojure (apparently) needs to breathe in some ugly OO syntax if you want to touch the (admittedly huge) Java ecosystem. Look I use JVM tech: Cassandra in particular, am very impressed with it (I also code in Java to the Bloomberg API - less impressed with that). I don't love the JVM as you've gathered, for purist reasons and the fact that it takes me into a slightly dull corporate sort of culture, but I know that it has advantages. Anyway fun sparring with you. good points.
    - 11y ago
brashrat 11y ago
the JVM abstraction isolates foreign java code into a sandbox. I don't want outside code running native on my machine.