3 ms·

I think putting more effort into Avian would probably be time better spent. Their static code-gen is lacking (it currently just runs the JIT ahead of time, inst

I think putting more effort into Avian would probably be time better spent. Their static code-gen is lacking (it currently just runs the JIT ahead of time, instead of taking more time with something like LLVM), but they've got a lot of things going for them including a superior GC.

bcg1 11y ago
I was wondering why no one mentioned Avian... I'm not a mobile developer so I wasn't sure, but I thought that it does the same thing essentially. Avian is a fantastic platform and the maintainers are true friends of free software, even though their license is as permissive as you can possibly get. https://github.com/ReadyTalk/avian https://github.com/ReadyTalk/avian
joel_dice 11y ago
I wrote most of the Avian VM, and I agree that the code generation is quite primitive compared to LLVM's. We've considered using LLVM as an alternative code generator, but hesitated partly because LLVM used to require a shadow stack to support accurate GC. I just checked they're latest docs[1], though, and it seems that there are other options now. All in all, adding LLVM support to Avian would be challenging but doable. However, Avian's generated code is already fast enough for most purposes, and it's not too hard to fall back to a bit of native code when you need maximum performance. My impression is that Java-on-iOS developers are less concerned about performance and more concerned with ease-of-use (e.g. tool integration) and convenient access to native APIs (e.g. Bro[2]). The RoboVM devs have apparently done a great job on both of those things. I sympathize with Zechner and the other RoboVM devs. Development on Avian was originally funded by the company I was working at since it neatly addressed a problem we had: extending the lifetime of a large body of client-side Java code in a world that was/is increasingly unfriendly to client-side Java. Once it was good enough for that purpose, there was no business reason to continue investing in it besides bug fixes and maintenance, so we had to move on to other things. I'd love to keep working on Avian full time and do cool stuff like an LLVM port or trace-based JIT compilation, but it's hard to justify when there are bills to pay. In my case, that means focusing primarily on other, income-producing projects. In RoboVM's case, it means trying a new approach to licensing to make development sustainable. I wish them luck with it. [1] http://llvm.org/docs/GarbageCollection.html http://llvm.org/docs/GarbageCollection.html [2] http://docs.robovm.com/advanced-topics/bro.html http://docs.robovm.com/advanced-topics/bro.html

bcg1 11y ago

I was wondering why no one mentioned Avian... I'm not a mobile developer so I wasn't sure, but I thought that it does the same thing essentially. Avian is a fantastic platform and the maintainers are true friends of free software, even though their license is as permissive as you can possibly get. https://github.com/ReadyTalk/avian https://github.com/ReadyTalk/avian

joel_dice 11y ago

I wrote most of the Avian VM, and I agree that the code generation is quite primitive compared to LLVM's. We've considered using LLVM as an alternative code generator, but hesitated partly because LLVM used to require a shadow stack to support accurate GC. I just checked they're latest docs[1], though, and it seems that there are other options now. All in all, adding LLVM support to Avian would be challenging but doable. However, Avian's generated code is already fast enough for most purposes, and it's not too hard to fall back to a bit of native code when you need maximum performance. My impression is that Java-on-iOS developers are less concerned about performance and more concerned with ease-of-use (e.g. tool integration) and convenient access to native APIs (e.g. Bro[2]). The RoboVM devs have apparently done a great job on both of those things. I sympathize with Zechner and the other RoboVM devs. Development on Avian was originally funded by the company I was working at since it neatly addressed a problem we had: extending the lifetime of a large body of client-side Java code in a world that was/is increasingly unfriendly to client-side Java. Once it was good enough for that purpose, there was no business reason to continue investing in it besides bug fixes and maintenance, so we had to move on to other things. I'd love to keep working on Avian full time and do cool stuff like an LLVM port or trace-based JIT compilation, but it's hard to justify when there are bills to pay. In my case, that means focusing primarily on other, income-producing projects. In RoboVM's case, it means trying a new approach to licensing to make development sustainable. I wish them luck with it. [1] http://llvm.org/docs/GarbageCollection.html http://llvm.org/docs/GarbageCollection.html [2] http://docs.robovm.com/advanced-topics/bro.html http://docs.robovm.com/advanced-topics/bro.html