llvm dev - Mar 2008 - [LLVMdev] Proposal for a Google summer of code project for the Java frontend.

Nicolas Geoffray wrote:
>
> There is no real missing feature. The VMs can execute standard 
> applications (last time I checked, the JVM can run tomcat), and the 
> implementations follow the VM specifications. The CLI implementation 
> lacks generics and overflow detection, but this is not top priority in 
> my mind.
>
> Among many features, here are the ones that I'd _love_ to see
implemented:
> 1) Compilation optimizations for type-safe languages (including 
> type-based alias analysis)
> 2) Hotspot-like vm: switching between interpreter and compiler, applying 
> different optimizations depending on a method's hotness, doing on-stack
> replacement
> 3) Implementing a garbage collector with llvm facilities: currently my 
> GC is not related to the compiler (consider it like Boehm's). It would 
> be nice to see how do the LLVM intrinsics fit with Java/CLI and JIT.
>
>   
I also forgot:
4) Generating shared libraries in order to not recompile Java or CLI 
code. In LLVM bitcode (simpler at first) and then in the ELF/MachO file 
format.

> Nicolas
>
>   
>> Ramon
>>
>> On Mon, Mar 17, 2008 at 9:48 PM, Nicolas Geoffray
>> <nicolas.geoffray at lip6.fr> wrote:
>>   
>>     
>>>  I'm in the process of checking in a Java and a CLI FE to the
llvm
>>>  repository. I'm not sure what's the shape of llvm-java. Do
your changes
>>>  make it run some applications?
>>>
>>>  Is the grant already provided? I'd be happy to mentor your
work if the
>>>  project can also concern improving my existing implementation ;-)
>>>
>>>     
>>>       
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>   
>>     
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Based on my experience this last one (the generation of shared
libraries) is the most important performance wise, and the one that
would make a difference from a performance point of view.

I would like to prepare a proposal as soon as posible. Could I have a
look at your code privately, even if there are licensing issues
pending? I understand that this issues are just temporary, and will in
no way block the publication of the code at a certain time.

Best regards,
Ramon

Ramón García wrote:
> Based on my experience this last one (the generation of shared
> libraries) is the most important performance wise, and the one that
> would make a difference from a performance point of view.
>
>   
That's more or less true: generating shared libraries will improve 
startup time, not steady-state time. It will decrease steady-state 
performance (both for Java and CLI) because the VMs ensure a class will 
be fully initialized before its use. Therefore, while the JIT will have 
runtime knowledge of a class being fully initialized or not, a static 
compiler will have to be conservative and insert intialization checks on 
most uses of a class.

What you can do to tackle this issue is to generate different native 
code statically and let the VM choose which native code it has to 
execute (depending on which classes were already initialized).
> I would like to prepare a proposal as soon as posible. Could I have a
> look at your code privately, even if there are licensing issues
> pending? I understand that this issues are just temporary, and will in
> no way block the publication of the code at a certain time.
>
>   
Do you really need the code for the proposal? Legally, I don't have the 
right (yet) to send it to you. Let's see how things go this week and 
hope that at the end of the week I'll be able to checkin the code.

Nicolas
> 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
>