Nicolas Geoffray
2008-Mar-18 11:17 UTC
[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 >
Ramón García
2008-Mar-18 13:09 UTC
[LLVMdev] Proposal for a Google summer of code project for the Java frontend.
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.
Nicolas Geoffray
2008-Mar-18 14:04 UTC
[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 >
Seemingly Similar Threads
- [LLVMdev] Proposal for a Google summer of code project for the Java frontend.
- [LLVMdev] Proposal for a Google summer of code project for the Java frontend.
- [LLVMdev] Proposal for a Google summer of code project for the Java frontend.
- [LLVMdev] Proposal for a Google summer of code project for the Java frontend.
- [LLVMdev] Proposal for a Google summer of code project for the Java frontend.