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

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
>

I would prefer to see actual code to make safe schedules. With code I can see
what changes one must make. I can also show in detail these changes,
which would give security to the LLVM project that the proposal is
viable. By contrast,
without code, neither me nor LLVM project can ensure that the project will
be successfully performed behind schedule. Since this is a difficult
project (we
are talking about compilers which are complicated technologies) it is specially
important to have a good planning.

On Tue, Mar 18, 2008 at 12:17 PM, Nicolas Geoffray
<nicolas.geoffray at lip6.fr> wrote:
>
>  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.
There was a misunderstanding. The issue with dynamic compiling is
not only startup time, but also memory consumption, and this is a *huge*
issue with Java applications. In addition, I think that in most of the cases
 a class can be initialized at compile time.

Ramón García wrote:
> I would prefer to see actual code to make safe schedules. With code I can
see
> what changes one must make. I can also show in detail these changes,
> which would give security to the LLVM project that the proposal is
> viable. By contrast,
> without code, neither me nor LLVM project can ensure that the project will
> be successfully performed behind schedule. Since this is a difficult
> project (we
> are talking about compilers which are complicated technologies) it is
specially
> important to have a good planning.
>
>   
OK, let's hope it'll be available soon enough then :)
> On Tue, Mar 18, 2008 at 12:17 PM, Nicolas Geoffray
> <nicolas.geoffray at lip6.fr> wrote:
>   
>>  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.
>>     
>
> There was a misunderstanding. The issue with dynamic compiling is
> not only startup time, but also memory consumption, 
Can you tell me why dynamic compilation consumes memory? Except the fact 
that you need to embed a JIT in your VM, dynamic compilation should not 
consume that much memory. Once a method is compiled you can throw away 
the intermediate representation. Or are you talking about constrained 
devices where you do not want to embed a JIT?
> and this is a *huge*
> issue with Java applications. In addition, I think that in most of the
cases
>  a class can be initialized at compile time.
>   
No. Initialization must happen during execution. By intialization, I 
mean calling the clinit function (e.g. static{...} in Java source), not 
resolving the class (which can be at compile time).

Nicolas
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>