This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Tricky Time Tradeoff
Posted by Bill Venners on 01 Jun 1998, 11:00 AM
> Thanks for the informative article on Hotspot. One thing not covered is the actual cpu time Hotspot's profiler takes to work out where the hotspots are. Surely if this is excessive it could cancel out the benefits obtained from optimization. There is is also the overhead in dynamic compilation.
True, in Hotspot you've got profiling going on and compilation
to native, which are taking up CPU time. In a traditional JIT
you also have compilation to native going on, which eats up CPU
So the CPU time spent doing this processing has to be recouped
in faster execution time, otherwise it's not worth doing the
processing in the first place. This is why they say that Hotspot
has more time to do a better job of optimization during the
compilation to native compared to a traditional JIT. Since
Hotspot is only converting and optimizing say 10 to 20 percent
of the methods to native, it has more time to spend on each
Sun didn't say what percentage of time their Hotspot VM spends
doing profiling. I didn't ask them that, so they might have an
answer to give out, but they might say that details like that
are proprietary. What we do know is that they would have to make
the CPU time spent profiling a good investment which returns
more CPU time later in the form of faster program execution.
To me it seems like finding the optimum tradeoff between
time spend profiling (and compilation/optimizing) and
increased execution speed would be quite tricky, and would
require a lot of empirical measuring and ingenuity. When we
finally get to see Hotspot for ourselves, we'll find out how
well they did initially. I expect Sun to be able to improve
this tradeoff over time, from release to release, as they get
more empirical information and more time to think up and try
out various tweaks to their algorithms.