[llvm-dev] A "Java Backend"

[Sanjoy Das via 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