Java: Dead code elimination

Question

I'd like to know how Java would handle the following scenario:

Suppose I have a class called Debug, which looks like this:

public class Debug 
{
    private static final boolean isAssertEnabled = true;

    public static void assertTrue(boolean b, String errorMessage) {
        if (isAssertEnabled) {
            if (!b) {
                throw new RuntimeException(errorMessage);
            }
        }
    }
}

and suppose my code has a call that looks something like this:

...
Debug.assertTrue((x + y != z) && (v - u > w), "Some error message");
....

I have a few questions:

1. If the isAssertEnabled flag is set to false, will the whole call to Debug.assertTrue be compiled out? Please note that the check if isAssertEnabled == true is only made inside the function after it was called.
2. If the whole call does get compiled out, does that also mean that the evaluation of the boolean expression is compiled out? Would be a waste to evaluate that expression for nothing.

Thanks for you help!

Freewheeling

Be aware of this #3302135 – Alternate

Answer 1

The evaluation of the boolean expression should not be compiled away - at least by javac.

Even if the Debug class file currently do nothing with the value, who's to say that that will be the case at execution time?

After making the Debug class compile (by making isAssertEnabled static), javac still includes the code - but I would expect the JIT compiler to remove it (although you should see the question Peter referenced). Whether it could then inline the method to nothing, I'm not sure. Again, if the JIT compiler could do that, and if it realized that evaluating the arguments couldn't have any side-effects, it could potentially avoid the evaluation. I wouldn't personally write code depending on that though.

Philina

Thanks! This would've been much more convenient than surrounding every call with an if, but oh well... And woops, forgot to make isAssertEnabled static :) – Freewheeling

@ykrasik: If we ever get concise closures, they'll make life easier :) – Philina

Answer 2

Why are you trying to build what Java already provides natively?

The assert keyword does exactly what you want: its execution can be turned on and off (on a per-package level) and the evaluation of the boolean expression is avoided when assertions are disabled.

Satan

Well, I'm trying to build this for Android, from what I gather assertions work a bit differently there, so instead I just decided to go for this simple implementation of my own. – Freewheeling

Answer 3

That reminds me of Log4j's "isTraceEnabled()", "isDebugEnabled()", and so on. Have to explicitly wrpa your log statements in if-statements to avoid unnecassary log statement evaluations.

if(logger.isDebugEnabled() {
        logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
}

see here under "Performance"

Stroganoff

Switch to logback and save yourself the wrapping: logger.debug("Entry number: {} is {}", i, entry[i]); is nearly free when disabled. – Fadge

Thanks for the pointer! However, the wrapper is only need in very few situations and just can be omitted most of the time. – Triliteral