4 ms·

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

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.

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.