Re: hex dump?
Andreas Leitgeb wrote:
It's all moot, anyway. Java apps just do have that relatively high
startup cost, so spending those additional cycles for ever-the-same
calculations really isn't all that sticking out. Probably, handling
pre-optimizations wouldn't be for free, either.
Plus HotSpot optimizations are dynamic. They get undone and redone as
the engine deems fit, i.e., as runtime considerations mutate.
Supposedly this allows HotSpot to do optimizations not even possible
with static (compile-time) optimization, such as guaranteeing that an
alias pointer is not used at a given time during some performance-
critical operation, thus allowing it to substitute a register access
instead of an interpreted lookup, or inlining a get method and
avoiding an instance creation because HotSpot can tell that the value
is not changed during this particular execution, or that some
operation's lock doesn't escape a critical section so that it can be
elided.
I say "supposedly" only because I've seen anecdotal evidence that this
magic doesn't occur as often or as aggressively as one might wish.
Also, JVMs vary with respect to their optimization capabilities.
--
Lew