4 ms·

They’re honestly not quite miscible. I know that, when .NET came out, everyone responded with “haha they copied Java,” but the truth is that they make a pile of

by gecko 8y ago

They’re honestly not quite miscible. I know that, when .NET came out, everyone responded with “haha they copied Java,” but the truth is that they make a pile of very different technical trade-offs. The CLR has explicit stack allocation, the JVM does not. The JVM is genuinely a JIT, the CLR is really all about AOT. The CLR has full support for low-level code (pointers and such), while the JVM does not. The JVM and its class library has been cross-platform from day one, the CLR in a meaningful sense has not. The CLR has a really simple FFI, the JVM traditionally has not. The CLR has reified generics, the JVM does not. The JVM has a much more advanced GC, the CLR’s use of value types and things like Span<> means that such an advanced GC is (at least arguably) not necessary, and so on. I really love the CLR, and I think it’s just as much “alien technology” as the JVM. I suspect the lack of love for it likely has more to do with the official versions being Windows-only than anything else. But I think it’s also just true that, while they both fill the same niche in a grand way (they’re both high-level VMs), their details are sufficiently different that a direct comparison doesn’t honestly make a ton of sense.

pvg 8y ago
that a direct comparison doesn’t honestly make a ton of sense. I think a comparison of them as products/platforms and the way the combination of technical and business decisions have influenced their trajectories is still interesting and instructive. Microsoft's very belated recognition that they won't be able to extend their OS dominance to all things server also means they've mostly squandered the technical advantages of the CLR. Oracle can catch up with the missing bits technologically (and they are doing just that) whereas it's by now really hard for the CLR to catch up in marketshare. Which is a pity.
mwcampbell 8y ago
Since you seem to have a strong understanding of both JVM and CLR, do you know if it would be feasible to translate CIL bytecode to JVM bytecode without having terrible performance in the translated code? In particular, I wonder if Xamarin.Android could do this (of course, in that case the JVM bytecode would be further translated to Dex), to provide an alternative to the current hairy interop situation with JNI and two GCs.
- kittiepryde 8y ago
  There was a project that could translate jvm to clr, http://weblog.ikvm.net/2017/04/21/TheEndOfIKVMNET.aspx http://weblog.ikvm.net/2017/04/21/TheEndOfIKVMNET.aspx It's retired now. I used it once, it worked pretty well.
  - mwcampbell 8y ago
    Yep, I've used that too. But I wonder if there are any hard problems translating in the other direction.
    - pjmlp 8y ago
      Lack of support for pointers, stack allocation, reference parameters, mixed-mode Assemblies are the first things that come to mind.
- gecko 8y ago
  I'm not sure, to be honest, but I'm a bit dubious. Some things would definitely be impossible to translate with good performance, such as unsigned types, checked arithmetic, and value types. Forgetting CIL translation, code that needs these things already runs very slowly on the JVM, even when translation isn't involved. (E.g., I think JGit is awesome, but the lack of unsigned values slows things down, as JGit has to promote integers or emulate types, depending.) But I don't know that these are so common that it'd generically be an issue. Other common things might be okay; Kotlin achieves C#-style generics by inlining all over the place, so I suppose a CIL translator could pull the same stunt. Likewise, while the JVM doesn't have a direct equivalent of stackalloc, I know the escape analysis has gotten pretty good, so maybe that'd work out okay anyway. IKVM had a comparatively easier job, since CIL is mostly a superset of the JVM bytecodes. (Note though that I have zero idea how GraalVM impacts any of this. It might completely negate all the things I flagged above.)
  - vbezhenar 8y ago
    Unsigned types should be possible to translate reasonably well. Addition is just the same, multiplication and division is performed via Integer.xxx methods and should be replaced by proper machine code by JIT.
eikenberry 8y ago
IMO pretty much no other language run-time is directly comparable to the JVM simply due to the VM part. Building an entire VM into your run-time comes at a huge complexity cost but is necessary for its goal of running on different hardware seamlessly. It is simply not worth it for most run-times to try for that level of binary compatibility when simpler solutions like cross compiling work most of the time.
- 0x0 8y ago
  Arguably .NET and the CLR is "an entire VM in the runtime", too.
- jfoutz 8y ago
  Smalltalk probably. Which iirc, was a pretty big influence on the JVM.
  - PeCaN 8y ago
    Sun literally bought the StrongTalk team to make StrongTalk into the JVM, so "pretty big influence" is something of an understatement.
    - dfox 8y ago
      From my very shallow understanding of CLR/CIL it seems to me that CLR's object model is significantly closer to Smalltalk than JVM's, at least because IIRC CLR has send-like opcode since the beginning, while JVM for a long time had only bunch of specialized invokefoo, with "call n-th method of something" semantics.
- pjmlp 8y ago
  Besides Smalltalk, Lisp and SELF come to mind.
- jcrites 8y ago
  Many other language runtimes (besides the Java JVM) are implemented as virtual machines: Python's most widely used CPython implementation uses a VM: https://leanpub.com/insidethepythonvirtualmachine/read https://leanpub.com/insidethepythonvirtualmachine/read Ruby "compiles the abstract syntax tree into lower-level byte code. This byte code is then run by the Ruby virtual machine.": http://blog.honeybadger.io/how-ruby-interprets-and-runs-your-programs/ http://blog.honeybadger.io/how-ruby-interprets-and-runs-your... Perl 6 runs on the Parrot VM: https://perl6.org/archive/architecture.html https://perl6.org/archive/architecture.html (and I believe Perl 5 had a different stack-based VM) These days, more interpreted languages use VMs than not. One notable language runtime that does not use a virtual machine is the Chrome V8 JavaScript engine, which I believe compiles JavaScript directly into machine code and then executes it.
Fede_V 8y ago
This is a fantastic post :) I'd love to see it fleshed out in a blog if you feel so inclined!

by gecko 8y ago

pvg 8y ago

that a direct comparison doesn’t honestly make a ton of sense. I think a comparison of them as products/platforms and the way the combination of technical and business decisions have influenced their trajectories is still interesting and instructive. Microsoft's very belated recognition that they won't be able to extend their OS dominance to all things server also means they've mostly squandered the technical advantages of the CLR. Oracle can catch up with the missing bits technologically (and they are doing just that) whereas it's by now really hard for the CLR to catch up in marketshare. Which is a pity.

mwcampbell 8y ago

Since you seem to have a strong understanding of both JVM and CLR, do you know if it would be feasible to translate CIL bytecode to JVM bytecode without having terrible performance in the translated code? In particular, I wonder if Xamarin.Android could do this (of course, in that case the JVM bytecode would be further translated to Dex), to provide an alternative to the current hairy interop situation with JNI and two GCs.

kittiepryde 8y ago
There was a project that could translate jvm to clr, http://weblog.ikvm.net/2017/04/21/TheEndOfIKVMNET.aspx http://weblog.ikvm.net/2017/04/21/TheEndOfIKVMNET.aspx It's retired now. I used it once, it worked pretty well.
- mwcampbell 8y ago
  Yep, I've used that too. But I wonder if there are any hard problems translating in the other direction.
  - pjmlp 8y ago
    Lack of support for pointers, stack allocation, reference parameters, mixed-mode Assemblies are the first things that come to mind.
gecko 8y ago
I'm not sure, to be honest, but I'm a bit dubious. Some things would definitely be impossible to translate with good performance, such as unsigned types, checked arithmetic, and value types. Forgetting CIL translation, code that needs these things already runs very slowly on the JVM, even when translation isn't involved. (E.g., I think JGit is awesome, but the lack of unsigned values slows things down, as JGit has to promote integers or emulate types, depending.) But I don't know that these are so common that it'd generically be an issue. Other common things might be okay; Kotlin achieves C#-style generics by inlining all over the place, so I suppose a CIL translator could pull the same stunt. Likewise, while the JVM doesn't have a direct equivalent of stackalloc, I know the escape analysis has gotten pretty good, so maybe that'd work out okay anyway. IKVM had a comparatively easier job, since CIL is mostly a superset of the JVM bytecodes. (Note though that I have zero idea how GraalVM impacts any of this. It might completely negate all the things I flagged above.)
- vbezhenar 8y ago
  Unsigned types should be possible to translate reasonably well. Addition is just the same, multiplication and division is performed via Integer.xxx methods and should be replaced by proper machine code by JIT.

eikenberry 8y ago

IMO pretty much no other language run-time is directly comparable to the JVM simply due to the VM part. Building an entire VM into your run-time comes at a huge complexity cost but is necessary for its goal of running on different hardware seamlessly. It is simply not worth it for most run-times to try for that level of binary compatibility when simpler solutions like cross compiling work most of the time.

0x0 8y ago
Arguably .NET and the CLR is "an entire VM in the runtime", too.
jfoutz 8y ago
Smalltalk probably. Which iirc, was a pretty big influence on the JVM.
- PeCaN 8y ago
  Sun literally bought the StrongTalk team to make StrongTalk into the JVM, so "pretty big influence" is something of an understatement.
  - dfox 8y ago
    From my very shallow understanding of CLR/CIL it seems to me that CLR's object model is significantly closer to Smalltalk than JVM's, at least because IIRC CLR has send-like opcode since the beginning, while JVM for a long time had only bunch of specialized invokefoo, with "call n-th method of something" semantics.
pjmlp 8y ago
Besides Smalltalk, Lisp and SELF come to mind.
jcrites 8y ago
Many other language runtimes (besides the Java JVM) are implemented as virtual machines: Python's most widely used CPython implementation uses a VM: https://leanpub.com/insidethepythonvirtualmachine/read https://leanpub.com/insidethepythonvirtualmachine/read Ruby "compiles the abstract syntax tree into lower-level byte code. This byte code is then run by the Ruby virtual machine.": http://blog.honeybadger.io/how-ruby-interprets-and-runs-your-programs/ http://blog.honeybadger.io/how-ruby-interprets-and-runs-your... Perl 6 runs on the Parrot VM: https://perl6.org/archive/architecture.html https://perl6.org/archive/architecture.html (and I believe Perl 5 had a different stack-based VM) These days, more interpreted languages use VMs than not. One notable language runtime that does not use a virtual machine is the Chrome V8 JavaScript engine, which I believe compiles JavaScript directly into machine code and then executes it.

Fede_V 8y ago

This is a fantastic post :) I'd love to see it fleshed out in a blog if you feel so inclined!