Re: Saving JIT work?

[Eugene Rosenzweig]

It is certainly an enticing idea. JIT compilation offers even more code
optimisation than conventional pre-compilation so it would be quite
interesting what would happen if someone did write a jvm with jit and an
executable caching scheme. The jvm would jit-compile the code and save the
results to be reused and ideally even profile the code even more with
subsequent runs (if required). There is an interesting article about HP
Dynamo project I remember that dealt with jit performance performance
benefits:
http://www.arstechnica.com/reviews/1q00/dynamo/dynamo-1.html

However the code size would grow dramatically, for every java class there
would be an executable cache which would probably more than double the
effective size of the class takes up on disk.

"Larry Meadors" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Are there any JITs that save what they do?
>
> What I mean is instead of compiling into memory and losing the work when
> the jvm exits, compiling to disk and reusing the compiled code later?
>
> That would be a killer tool.
>
> Larry
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Saving JIT work?

[Marco Trevisan]

Hi,

Eugene Rosenzweig wrote:

However the code size would grow dramatically, for every java class there
would be an executable cache which would probably more than double the
effective size of the class takes up on disk.
And there is another reason for not doing this. Here is a snapshot of:

http://developer.java.sun.com/developer/community/chat/JavaLive/2002/jl1015.html

*/"/*

*//dev/null/*: Can you explain the differences between the client and 
server HotSpot VMs in 1.3.1 and 1.4 for Linux? Also, why does the server 
VM sometimes have significantly worse performance for a servlet-based 
application?

*Hui Huang*: Both the client and server compilers use the profiling 
information gathered by the interpreter to decide which method to 
compile. The difference is that the server compiler has a much higher 
threshold, and it does more aggressive optimizations. If your 
application lasts for only a short period of time, it likely will run 
slower on the server compiler, because most of its time will be spent in 
the interpreter.

[...]

*/Moises Lejter/*: Does the expensive optimization run on a thread of 
its own? Could the threshold for the server optimizations be lowered? I 
am working on a Java client app that is expected to run hours at a time, 
rather than minutes, and it might benefit from the more aggressive 
optimizations -- if we could do it with little impact on the user's 
experience.

*Hui Huang*: The problem with lowering the compiler threshold is that 
you will get less accurate data from the interpreter, and that will 
affect the code quality.
"





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]