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]
