retard wrote:
Tue, 16 Feb 2010 21:11:32 +0100, grauzone wrote:
retard wrote:
Granted, even if logging is disabled, the compiler will push the
arguments on the stack and call logInfo().
This is a case where a JIT compiler wins. The code runs equally fast
without the call at all and with logging turned off (dynamically). In
languages like D, the like has to be statically turned off unless
compilers have any new dynamic optimizations.
Can the JIT really do this optimization? It sounds as if it'd detect
that the variable never changes, and generate code with that fixed
value.
It sure can recompile the code assuming that the logging policy doesn't
change that often - in case it does change often switching the code might
have larger overhead than testing the condition. In real life you would
probably start the program with either logging on or off. With JIT
compiled languages, the decision can be postponed to runtime, in D it
We're talking about a globally accessible runtime variable here, right?
Not just a local variable that was detected to be constant. What I don't
understand is: how does the VM efficiently detect, that the value never
changes, and that generating code for that fixed value may be worthwhile?
It is well possible in theory: the VM could just set up write barriers
to detect changes to a variable, and then recompile speed critical code
that uses the variable.
But it had to collect statistics about all accessed variables, and then
decide to recompile the code. Both collecting and analyzing statistics
and recompiling code takes time, and it has to be fast enough to not
slow down the program even if there are "misses" (e.g. unexpected
variable writes).
Other typical JIT optimizations sound easy compared to this case. I'd be
really interested how this works out.
probably has to be done on compile time and provide two binaries, if both
logging and efficiency are required options. I can post a rather short
test case in Java/Scala here, if you insist.
