[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