[LLVMdev] Introducing myself, and Java project.

[Ted Neward]

You probably want to sit down and have a long talk with Jeroen Frijters, the
principal behind the IKVM project.

Note that you will have to deal with ClassLoaders at some level, regardless
of what you'd prefer.

> A more obvious problem is, of course, that it is not possible to
> compile Java code statically and save the result in the disk.
>
That is untrue--last time I checked, gcj does this out of the box. Several
other tools used to (TowerJ, I think its name was), but the demand for this
turned out to be nil and they folded. Most of Java's appeal lies in its
ability to dynamically link libraries.

And quite frankly, the overhead of passing native data across that JNI
boundary is generally pretty tiny, unless you do some truly idiotic things
in either your Java or your JNI/C++ code. I still wouldn't want to do it in
a tight loop, mind you, but it's generally not more than a handful of
assembly instructions. (This is what I've been told, anyway--I haven't pored
over the OpenJDK sources to find the actual code that does the translation.)

Having said that, I think a JVM->LLVM bytecode converter is a really cool
idea. But I think you're ultimately going to come to the same decision IKVM
did, which is to support ClassLoading as well as static loading.

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com
 

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Ramón García
> Sent: Saturday, February 02, 2008 5:48 PM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] Introducing myself, and Java project.
> 
> Hello, I am Ramon Garcia Fernandez. My interest in LLVM is to develop
> an interface for Java virtual machine bytecodes, so that Java programs
> can be run under LLVM.
> 
> You may ask why not using the Java virtual machine. Although it may be
> improved, there are some misfeatures in it. This is what I have
> learned. It makes the communication with native code too expensive.
> Passing an array from native to the virtual machine or vice versa
> requires a copy of the data. Why? you may ask. Because Java uses
> garbage collectors based on copying. Thus the position of an object
> may be moved by the virtual machine. The implementation of
> generational garbage collection in Java uses areas of memory for each
> generation, so that when an object changes from the young generation
> to the old its storage must be moved. This may give some performance
> advantage, by making young objects close in memory, but with the cost
> of making exchange of data with native code expensive. In particular,
> data copying is required for reading and writing files, sending or
> receiving data from the network, or drawing. Since Java is not often
> used for numerical analysis or tasks that require little data exchange
> with the outside world, I disagree that the implementation with a
> copying collector is good for most applications.
> 
> A more obvious problem is, of course, that it is not possible to
> compile Java code statically and save the result in the disk.
> 
> So I am starting to write a compiler of Java bytecode to LLVM
> bytecode. For now I am designing, dealing with things such as how to
> assign stack positions to the operands of each instruction.
> 
> My target is to deliver something simple. Operations such as
> classloader creation and dynamic class loading will not be supported.
> 
> Hoping that this is the start of a long term cooperation,
> 
>     Ramon
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date:
> 2/2/2008 1:50 PM
> 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: 2/2/2008
1:50 PM