[LLVMdev] Proposal for a Google summer of code project for the Java frontend.

Nicolas Geoffray nicolas.geoffray at lip6.fr
Tue Mar 18 07:04:35 PDT 2008


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
>   




More information about the llvm-dev mailing list