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

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
>

The memory consumed by the code compiled is huge in server applications. And
it is not shared by different virtual machine instances. By contrast,
shared libraries
are memory mapped, therefore they are shared between different instances of the
executables using them. It is posible to throw away code after using
it, but then
compilation cost would be repeated.

And dynamic compilation prevents expensive optimization techniques.
>  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?
Ramon

OK, I didn't realize you were not one-JVM oriented. Sure, if the code 
can be shared between different instances of JVMs, that would be great! 
I actually had this in mind when I wrote the proposition :)

Ramón García wrote:
> The memory consumed by the code compiled is huge in server applications.
And
> it is not shared by different virtual machine instances. By contrast,
> shared libraries
> are memory mapped, therefore they are shared between different instances of
the
> executables using them. It is posible to throw away code after using
> it, but then
> compilation cost would be repeated.
>
> And dynamic compilation prevents expensive optimization techniques.
>
>   
>>  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?
>>     
>
> Ramon
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Am Dienstag, den 18.03.2008, 15:31 +0100 schrieb Ramón
García:
> The memory consumed by the code compiled is huge in server applications.
Do you have statistics about the relative footprints of code and various
kinds of objects in such a server application?
I know they have huge footprints (a general problem with Java
applications, I think), but I never got a useful breakdown along the
lines of what's responsible for that.
>  And
> it is not shared by different virtual machine instances. By contrast,
> shared libraries
> are memory mapped, therefore they are shared between different instances of
the
> executables using them. It is posible to throw away code after using
> it, but then
> compilation cost would be repeated.
It would suffice to store a hash of the compiled code. That way, when
the same class somes along, you can reuse existing compiled code.

You'd want to keep the intermediate code if you try global optimizations
like monomorphisation (i.e. finding out those parameters and variables
that are never assigned to polymorphically - loading another class can
invalidate assumptions, so you may have to redo at least parts of the
optimization).
> And dynamic compilation prevents expensive optimization techniques.
Well, then a hash should really be sufficient :-)

Regards,
Jo