I have just worked with this code. The architecture is fine, and I think that this code should be reused, It needs updating, however, because it does not compile with LLVM 2.1 (I prefer to use a stable version to focus my work, and port to LLVM 2.2 later). I have seen that one incompatibility is that this Java frontend requires C++ with exceptions, but LLVM is compiled with -fno-exceptions. For now, I am compiling with -fexceptions. Should exceptions be removed from the code of the Java frontend? Then, I have doubts about whether the changes for getting it built are correct or not. I will make more questions later. This could be a work plan: * Getting the java frontend built. * Implement exception handling (jsr/ret bytecodes) * Implement garbage collection. * Support JAR files. This should get an usable Java implementation. But there is still very hard work to be done. The difficult part is dynamic class loading, reflection and creation of classloaders. This would enable to use LLVM for Java server applications such as Tomcat or JBoss. I am not sure if this work is possible without funding a full time position. Just some questions to think about it. To what extent does LLVM support dynamic code loading? Is it posible to get code loaded at runtime? Could this break assumptions made by interprocedural optimization? (A function may be called in unexpected ways) Another difficult part is optimization. In order to get good performance, references should be converted to values whenever possible. Recent virtual machines support scape analysis, so that local references can be converted into values, and be stored and released in the stack. This should be generalized to references that are class members. Java code is particular hard to optimize because any function call is a virtual function call. Is inlining posible? Only if one makes assumptions about any code using some class, that no other class is going to override the called method. Programmers could declare methods final, but this is rarely done. Assumptions may be checked for all loaded classes, but, for classes not yet loaded (and which may be loaded dynamically), who nows? But this is for very long term feature. For now, let us have fun completing the doable parts. Best regards, Ramon
Hi Ramon, On Feb 4, 2008 5:09 AM, Ramón García <ramon.garcia.f+llvm at gmail.com> wrote:> Java code is particular hard to optimize because any function call is > a virtual function call. Is inlining posible?It's possible if you do "method devirtualization" optimization first. No idea if LLVM supports that, though. Pekka
On Feb 3, 2008, at 7:09 PM, Ramón García wrote:> I have just worked with this code. The architecture is fine, and I > think that this code should be reused, > It needs updating, however, because it does not compile with LLVM 2.1 > (I prefer to use a stable version > to focus my work, and port to LLVM 2.2 later). >LLVM 2.2 comes out in a week, I would recommend using that over 2.1 if you must use a release. You can use the pre-releases to get started. However, if you are going to be actively developing you should use llvm svn. -Tanya> I have seen that one incompatibility is that this Java frontend > requires C++ with exceptions, but LLVM is compiled with > -fno-exceptions. For now, I am compiling with -fexceptions. Should > exceptions be removed from the code of the Java frontend? > > Then, I have doubts about whether the changes for getting it built are > correct or not. I will make more questions later. > > This could be a work plan: > > * Getting the java frontend built. > > * Implement exception handling (jsr/ret bytecodes) > > * Implement garbage collection. > > * Support JAR files. > > This should get an usable Java implementation. But there is still very > hard work to be done. The difficult part is dynamic class loading, > reflection and creation of classloaders. This would enable to use LLVM > for Java server applications such as Tomcat or JBoss. I am not sure if > this work is possible without funding a full time position. Just some > questions to think about it. To what extent does LLVM support dynamic > code loading? Is it posible to get code loaded at runtime? Could this > break assumptions made by interprocedural optimization? (A function > may be called in unexpected ways) > > Another difficult part is optimization. In order to get good > performance, references should be converted to values whenever > possible. Recent virtual machines support scape analysis, so that > local references can be converted into values, and be stored and > released in the stack. This should be generalized to references that > are class members. > > Java code is particular hard to optimize because any function call is > a virtual function call. Is inlining posible? Only if one makes > assumptions about any code using some class, that no other class is > going to override the called method. Programmers could declare methods > final, but this is rarely done. Assumptions may be checked for all > loaded classes, but, for classes not yet loaded (and which may be > loaded dynamically), who nows? > > But this is for very long term feature. For now, let us have fun > completing the doable parts. > > Best regards, > > Ramon > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Thanks. I have just downloaded LLVM tag release 2.2. From time to time, I will try working with SVN trunk release. But please understand that I would rather avoid fighting with compilation problems or temporary bugs that would distract me.> LLVM 2.2 comes out in a week, I would recommend using that over 2.1 > if you must use a release. You can use the pre-releases to get > started. However, if you are going to be actively developing you > should use llvm svn. > > -Tanya >
Seemingly Similar Threads
- [LLVMdev] Introducing myself, and Java project.
- [LLVMdev] Introducing myself, and Java project.
- [LLVMdev] Introducing myself, and Java project.
- [LLVMdev] Introducing myself, and Java project.
- [LLVMdev] Proposal for a Google summer of code project for the Java frontend.