My idea was to create a complete backend treating Java as a normal platform, to enable LLVM to compile programs to Java Bytecode (.class) and Java Archive files (.jar). This could be useful in situations where we need to compile a program for a platform still not natively supported by LLVM. I don't know if it exists already, I've heard about this "LLJVM" but I don't think it does the same thing as my idea. What do you think?
On 19 Jul 2016, at 04:06, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > My idea was to create a complete backend treating Java as a normal platform, to enable LLVM to compile programs to Java Bytecode (.class) and Java Archive files (.jar). This could be useful in situations where we need to compile a program for a platform still not natively supported by LLVM. > > I don't know if it exists already, I've heard about this "LLJVM" but I don't think it does the same thing as my idea. > What do you think?I think that it will be difficult. Java bytecode is intrinsically designed to be memory safe, whereas LLVM IR is not. There is no equivalent of inttoptr or ptrtoint in Java bytecode and the closest equivalent of a GEP is to retrieve a field from an object (though that’s only really for GEP + load/store). You could potentially do something a bit ugly and treat all of LLVM memory as one big ByteBuffer object, and make pointers indexes into this, but then you’d make it very hard for your LLVM-originating code to interoperate with Java-originating code and so you’d have to write a lot of code to take the place of the system call layer. Oh, and I doubt that you’ll find many more platforms that have a fully functional JVM than are LLVM targets. Even big-endian MIPS64 is not well-supported by Java (JamVM - a pure interpreter - is the only thing that we’ve managed to find that works). David -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3719 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160719/4241421e/attachment.bin>
Hi Lorenzo, One related project (though not exactly what you want) is https://github.com/graalvm/sulong -- Sanjoy Lorenzo Laneve via llvm-dev wrote:> My idea was to create a complete backend treating Java as a normal platform, to enable LLVM to compile programs to Java Bytecode (.class) and Java Archive files (.jar). This could be useful in situations where we need to compile a program for a platform still not natively supported by LLVM. > > I don't know if it exists already, I've heard about this "LLJVM" but I don't think it does the same thing as my idea. > What do you think? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hi, David Chisnall via llvm-dev wrote: > On 19 Jul 2016, at 04:06, Lorenzo Laneve via llvm-dev<llvm-dev at lists.llvm.org> wrote: >> My idea was to create a complete backend treating Java as a normal platform, to enable LLVM to compile programs to Java Bytecode (.class) and Java Archive files (.jar). This could be useful in situations where we need to compile a program for a platform still not natively supported by LLVM. >> >> I don't know if it exists already, I've heard about this "LLJVM" but I don't think it does the same thing as my idea. >> What do you think? > > I think that it will be difficult. Java bytecode is intrinsically designed to be memory safe, whereas LLVM IR is not. There is no equivalent of inttoptr or ptrtoint in Java bytecode and the closest equivalent of a GEP is to retrieve a field from an object (though that’s only really for GEP + load/store). > > You could potentially do something a bit ugly and treat all of LLVM memory as one big ByteBuffer object, and make pointers indexes into this, but then you’d make it very hard for your LLVM-originating code to interoperate with Java-originating code and so you’d have to write a lot of code to take the place of the system call layer. The caveat here is that Java has this "private" but-not-really-in-practice API called sun.misc.Unsafe that can be used to access native memory. So you can have (I'm paraphrasing, the method names may not match): long addr = unsafe.allocateMemory() unsafe.putInt(addr + 48, 9001); int val = unsafe.getInt(addr + 48); etc. You may even get decent performance out of this since JIT compilers tend to have to optimize these well (they're commonly uses in the implementation of some popular JDK classes). But you're right that it will still be difficult to naively inter-operate between Java and C++ objects. Which is why it will be an interesting research project. :) -- Sanjoy > Oh, and I doubt that you’ll find many more platforms that have a fully functional JVM than are LLVM targets. Even big-endian MIPS64 is not well-supported by Java (JamVM - a pure interpreter - is the only thing that we’ve managed to find that works). > > David > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Also potentially interesting; http://nestedvm.ibex.org/ On Tue, Jul 19, 2016 at 12:36 PM, Lorenzo Laneve via llvm-dev < llvm-dev at lists.llvm.org> wrote:> My idea was to create a complete backend treating Java as a normal > platform, to enable LLVM to compile programs to Java Bytecode (.class) and > Java Archive files (.jar). This could be useful in situations where we need > to compile a program for a platform still not natively supported by LLVM. > > I don't know if it exists already, I've heard about this "LLJVM" but I > don't think it does the same thing as my idea. > What do you think? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/396946f2/attachment.html>
That's an interesting project but I'd like to give LLVM this "power" lol Isn't it applied to GCC?> On Jul 21, 2016, at 9:11 AM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote: > > Also potentially interesting; > http://nestedvm.ibex.org/ > > >> On Tue, Jul 19, 2016 at 12:36 PM, Lorenzo Laneve via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> My idea was to create a complete backend treating Java as a normal platform, to enable LLVM to compile programs to Java Bytecode (.class) and Java Archive files (.jar). This could be useful in situations where we need to compile a program for a platform still not natively supported by LLVM. >> >> I don't know if it exists already, I've heard about this "LLJVM" but I don't think it does the same thing as my idea. >> What do you think? >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160721/30b44e17/attachment.html>