[LLVMdev] java frontend

[Alexander Betts]

On Jul 26, 2012, at 8:22 AM, Duncan Sands wrote:

> the main issue I know about is that gcj wants to output constructors and
> destructors directly to the assembly file, and completely bypasses gcc's
> generic machinery for this (probably because gcj predates that machinery).
> This is one reason why you can't do link-time optimization with gcc (which
> relies on everything going through the generic gcc machinery) and is also why
> java compiled with dragonegg doesn't work (generated assembler lacks
> constructors/destructors).  In my opinion this wouldn't be too hard to fix.
> 
> Another issue with gcj is that it's unmaintained (AFAIK), which probably also
> explains why it was never updated to support LTO.
> 
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

I've been investigating this some today, and I've been able to get a small Java program (a fairly simple sketch made in the Processing environment), compiled with gcj using DragonEgg, to run on an x86_64 system running CentOS 5 (this is with llvm-3.1, DragonEgg-3.1, and gcc 4.7.0).

I'm attaching the hacked gcc-4.7.0/gcc/java/class.c file, in case anyone's interested. The issue I encountered is that my program's Java classes weren't getting registered with the VM (indeed for the reasons presented above). class.c has a pathway that generates calls to libjava's _Jv_RegisterClass function; these calls evidently do get preserved in DragonEgg's output, and will register the classes when the program is run. So my version of class.c just forces this pathway to be executed by gcj no matter what.

-- Alex

-------------- next part --------------
A non-text attachment was scrubbed...
Name: class.c
Type: application/octet-stream
Size: 100733 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120814/57710c33/attachment.obj>