On 2013-01-24 10:13, Mario Zechner wrote:
> Can you give more technical details? i.e. what are the limitations, what GC is used, is JNI supported, is this based on VMKit?
1. RoboVM can not and never will be able to load Java bytecode
dynamically. Bytecode is compiled ahead-of-time into machine code and
linked into a single binary. So you could say that RoboVM isn't really a
virtual machine since it doesn't interpret bytecode. This is by design
since non jailbroken iOS devices wouldn't allow JITted code to be run
(memory pages cannot be made executable in iOS). Since bytecode cannot
be loaded dynamically there are never more than two classloaders in a
RoboVM app, the boot classloader and user classloader.
2. No JNI through dynamic library loading. Apple doesn't allow iOS apps
in the App Store that include dynamic libraries.
Yes, RoboVM implements JNI but on iOS the JNI library code has to be
statically linked into the executable. Statically linked JNI code in
user classes hasn't actually been implemented yet but it should be
trivial since it has already been done for the core classes. We've
implemented as much of the JNI API as have been needed so far. If you
want to know exactly how much please see the JNI API implementation in
RoboVM uses the Boehm-Demers-Weiser  as used by many other projects.
The stack, static data areas and data structures used by the vm code are
scanned conservatively while Java objects are precisely GCed.
RoboVM is not based on VMKit but we do use LLVM for the machine code
Are you working on something that you would consider using RoboVM for?
Please let me know the details and I will try to tell you whether RoboVM
will fit your needs in the future once it matures.