4 ms·

I've successfully used RoboVM to ship native linux binaries from jvm bytecode, in addition to the headlining cross-platform-mobile features. It's fantastic. I

I've successfully used RoboVM to ship native linux binaries from jvm bytecode, in addition to the headlining cross-platform-mobile features. It's fantastic. It worked pretty much out-of-box with a few commands from the Getting Started page. And as for performance: startup time is impressive: an order of magnitude faster than launching a jar in the jvm, such that you can actually use it in the middle of other shell scripts without blinking. Once it's been running for a while, it's hard to beat the kind of optimizations a JIT compiler can do, but RoboVM is still approximately as fast as java (I think the mailing list handwaves this to about 2x slower; still a couple hundred times faster than most interpreted languages, so I'm pretty okay with this). RoboVM uses the Boehm GC, which is mature, effective, and (of critical note to me) a heap-compacting garbage collector... which means you can confidently use it even for applications with days or months of contiguous uptime. I've thrown wicked strange bytecode at RoboVM. It copes fine; I was impressed. (After some time working in golang gave me a great appreciation for the semantic style of goroutines, I've been trying to bring them everywhere. I made some custom bytecode with code derived from the Apache JavaFlow library to try to break RoboVM, and it didn't even blink; I'm now using it with http://paralleluniverse.co/quasar/ http://paralleluniverse.co/quasar/ very happily.) And did I mention how pleasant it is to ship statically linked native executables?

yoklov 13y ago
I'm pretty sure the Boehm GC isn't heap compacting. It at least didn't used to be, and if it is it works in some way I cannot fathom, as I'm not sure how you can compact the heap without changing the value of pointers, which the Boehm GC cannot do safely. That said it's still a very good GC and you should be fine. (It does try to minimize fragmentation in other ways, but nothing is as effective as heap compacting.)
- heavenlyhash 13y ago
  Niklas (the RoboVM lead dev) talked briefly about how the GC is used on the list here: https://groups.google.com/d/msg/robovm/etAxWMYvRTU/huXKmPA-JT0J https://groups.google.com/d/msg/robovm/etAxWMYvRTU/huXKmPA-J... If I understand correctly, when used in "precise" mode, the Boehm GC is capable of compacting. Mono north of version 2.8 also claims to be heap compacting by virtue of Boehm in precise mode.
  - ntherning 13y ago
    I'm afraid that you are mistaken about the capabilities of the Boehm GC when it comes to compacting. It doesn't compact so heap fragmentation is a possibility with RoboVM. Mono 2.8 introduced SGen [0] which is a totally separate GC developed by the Mono project. It is a compacting GC and is now the default IIUC. /Niklas [0] http://www.mono-project.com/Working_With_SGen http://www.mono-project.com/Working_With_SGen
    - heavenlyhash 13y ago
      Ah, I stand corrected. (I had drawn my impression of Mono from https://en.wikipedia.org/wiki/Boehm_garbage_collector#Uses_and_ports https://en.wikipedia.org/wiki/Boehm_garbage_collector#Uses_a... 's current statement: "The Boehm GC is used by many projects that are implemented in C or C++, as well as by runtime environments for a number of other languages, including [...], the Mono implementation of the Microsoft .NET platform (also using precise compacting GC since version 2.8)"... which evidentially is referring to "also" a different GC entirely, rather than a mode as I had thought.) Do you know of any good resources that explain more about the precise vs conservative scanning modes of Boehm? I thought I recalled some references to a precise mode available via a "GC_MALLOC_ATOMIC" function in Boehm which would understand all of the contained data to be not-pointers and thus enable smarter handling, but perhaps that's a necessary-but-not-sufficient thing on the road to heap compacting. I'm hitting a lot of dead links looking for more information sadly; hpl.hp.com seems to have suffered a reorganization lately :( EDIT: http://hboehm.info/gc/ http://hboehm.info/gc/ appears to be the living mirror of http://www.hpl.hp.com/personal/Hans_Boehm/gc/ http://www.hpl.hp.com/personal/Hans_Boehm/gc/ and contains useful documentation and FAQs.
e12e 13y ago
Hm, seems documentation for for targeting Linux as a build target is missing? Or am I just looking in the wrong place?
- spullara 13y ago
  I was wondering the same thing.
- heavenlyhash 13y ago
  Perhaps the docs don't highlight it enough, but I think you should find what you're looking for under http://www.robovm.com/docs#using-the-command-line-tool http://www.robovm.com/docs#using-the-command-line-tool It's actually what you get when building on linux with no special args: the default behavior is to produce a binary for the current operating system and architecture. Thereafter, if you want to get fancier and target other specific systems, there are options for "-os", "-arch", and "-cpu"; you can find some description of them in the default usage help message from running `robovm` with no commands.
  - ntherning 13y ago
    Just to add some more info: We used to have instructions for installing and compiling under Linux. Since our main focus is currently iOS and some users were confused by mentioning Linux and thought that they could cross-compile for iOS on Linux we removed those instructions from the web site. Only Linux x86 can be targeted when compiling under Linux. Here's what you need to install if you are running Ubuntu 12.04: sudo apt-get install build-essential g++-multilib openjdk-7-jdk Then you also need to download an ICU data file and place it in /usr/share/icu: sudo mkdir -p /usr/share/icu sudo sh -c 'curl "http://download.robovm.org/icudt48l.dat" > /usr/share/icu/icudt48l.dat' From then on you should be able to follow the command line usage instructions to compile Linux x86 executables.
    - e12e 13y ago
      [edit: are you saying only 32-bit Linux can be targeted, and not 64bit/multiarch?] Thank you both, after looking harder at the documentation I figured out as much (except for the icu-part, I don't think that's mentioned anywhere). Unfortunately I had to give up building under Debian 7.0 (wheezy/stable) -- even after trying with both open jdk7, oracle jdk 7 and 8, standard llvm as well as llvm 3.5 and a newer cmake (in each case the jni/llvm-bindings doesn't build, as maven fails the second test-case). And the binary distribution is linked against a newer libc than I have. I guess it'll be possible to get it to run in an Ubuntu VM/chroot -- but I haven't tried that yet.

yoklov 13y ago

I'm pretty sure the Boehm GC isn't heap compacting. It at least didn't used to be, and if it is it works in some way I cannot fathom, as I'm not sure how you can compact the heap without changing the value of pointers, which the Boehm GC cannot do safely. That said it's still a very good GC and you should be fine. (It does try to minimize fragmentation in other ways, but nothing is as effective as heap compacting.)

heavenlyhash 13y ago
Niklas (the RoboVM lead dev) talked briefly about how the GC is used on the list here: https://groups.google.com/d/msg/robovm/etAxWMYvRTU/huXKmPA-JT0J https://groups.google.com/d/msg/robovm/etAxWMYvRTU/huXKmPA-J... If I understand correctly, when used in "precise" mode, the Boehm GC is capable of compacting. Mono north of version 2.8 also claims to be heap compacting by virtue of Boehm in precise mode.
- ntherning 13y ago
  I'm afraid that you are mistaken about the capabilities of the Boehm GC when it comes to compacting. It doesn't compact so heap fragmentation is a possibility with RoboVM. Mono 2.8 introduced SGen [0] which is a totally separate GC developed by the Mono project. It is a compacting GC and is now the default IIUC. /Niklas [0] http://www.mono-project.com/Working_With_SGen http://www.mono-project.com/Working_With_SGen
  - heavenlyhash 13y ago
    Ah, I stand corrected. (I had drawn my impression of Mono from https://en.wikipedia.org/wiki/Boehm_garbage_collector#Uses_and_ports https://en.wikipedia.org/wiki/Boehm_garbage_collector#Uses_a... 's current statement: "The Boehm GC is used by many projects that are implemented in C or C++, as well as by runtime environments for a number of other languages, including [...], the Mono implementation of the Microsoft .NET platform (also using precise compacting GC since version 2.8)"... which evidentially is referring to "also" a different GC entirely, rather than a mode as I had thought.) Do you know of any good resources that explain more about the precise vs conservative scanning modes of Boehm? I thought I recalled some references to a precise mode available via a "GC_MALLOC_ATOMIC" function in Boehm which would understand all of the contained data to be not-pointers and thus enable smarter handling, but perhaps that's a necessary-but-not-sufficient thing on the road to heap compacting. I'm hitting a lot of dead links looking for more information sadly; hpl.hp.com seems to have suffered a reorganization lately :( EDIT: http://hboehm.info/gc/ http://hboehm.info/gc/ appears to be the living mirror of http://www.hpl.hp.com/personal/Hans_Boehm/gc/ http://www.hpl.hp.com/personal/Hans_Boehm/gc/ and contains useful documentation and FAQs.

e12e 13y ago

Hm, seems documentation for for targeting Linux as a build target is missing? Or am I just looking in the wrong place?

spullara 13y ago
I was wondering the same thing.
heavenlyhash 13y ago
Perhaps the docs don't highlight it enough, but I think you should find what you're looking for under http://www.robovm.com/docs#using-the-command-line-tool http://www.robovm.com/docs#using-the-command-line-tool It's actually what you get when building on linux with no special args: the default behavior is to produce a binary for the current operating system and architecture. Thereafter, if you want to get fancier and target other specific systems, there are options for "-os", "-arch", and "-cpu"; you can find some description of them in the default usage help message from running `robovm` with no commands.
- ntherning 13y ago
  Just to add some more info: We used to have instructions for installing and compiling under Linux. Since our main focus is currently iOS and some users were confused by mentioning Linux and thought that they could cross-compile for iOS on Linux we removed those instructions from the web site. Only Linux x86 can be targeted when compiling under Linux. Here's what you need to install if you are running Ubuntu 12.04: sudo apt-get install build-essential g++-multilib openjdk-7-jdk Then you also need to download an ICU data file and place it in /usr/share/icu: sudo mkdir -p /usr/share/icu sudo sh -c 'curl "http://download.robovm.org/icudt48l.dat" > /usr/share/icu/icudt48l.dat' From then on you should be able to follow the command line usage instructions to compile Linux x86 executables.
  - e12e 13y ago
    [edit: are you saying only 32-bit Linux can be targeted, and not 64bit/multiarch?] Thank you both, after looking harder at the documentation I figured out as much (except for the icu-part, I don't think that's mentioned anywhere). Unfortunately I had to give up building under Debian 7.0 (wheezy/stable) -- even after trying with both open jdk7, oracle jdk 7 and 8, standard llvm as well as llvm 3.5 and a newer cmake (in each case the jni/llvm-bindings doesn't build, as maven fails the second test-case). And the binary distribution is linked against a newer libc than I have. I guess it'll be possible to get it to run in an Ubuntu VM/chroot -- but I haven't tried that yet.