cost of Java "assert" when disabled?

[David Holmes]

On 17/02/2012 9:40 AM, Vitaly Davidovich wrote:
> The asserts can be enabled/disabled at startup time, but I don't consider
> that an advantage over conditional compilation.  In fact, it's less
> convenient in some cases, e.g. you can't conditionally add/remove class
> fields, can't surround blocks of code with condition, etc.  There are
> workarounds, but it's not ideal.

I'm not going to get drawn into the whole "conditional compilation is 
[not] evil" debate. :) If I recall correctly the suggested buld-time 
idiom was to do:

static final boolean ASSERT = true; // or false

...

if (ASSERT)
    assert ...

that way you could compile with ASSERT set true to get assertions in the 
code; or false to have them elided by javac.

> C#/.Net have conditional compilation (conditional blocks + assert
> statements) and it's a handy tool and no need to worry about dead IL code
> causing opto issues - don't see a reason why java couldn't have done the
> same from the beginning.

Simply because the people defining the language didn't want it. I 
suspect there's a blog or two out there somewhere discussing this.

David
-----


>
> Sent from my phone
> On Feb 16, 2012 6:16 PM, "David Holmes"<david.holmes at oracle.com>  wrote:
>
>> The corelibs side of things seems to have gotten dropped from the cc list
>> - added back.
>>
>> On 17/02/2012 8:21 AM, Vitaly Davidovich wrote:
>>
>>> Don't want to sidetrack this thread but I really wish javac had proper
>>> conditional compilation support, which would make this issue mostly moot.
>>>
>>
>> But the whole point of Java assertions is to make them available at
>> runtime. I seem to recall a very similar question only recently on the
>> core-libs mailing list.
>>
>> So summary is:
>>
>> - Every assert requires checking if asserts are enabled
>> - JIT Compiler can elide the checks
>> - Presence of assert related bytecodes can impact JIT compiler inlining
>> decisions
>>
>> David
>>
>>   Sent from my phone
>>>
>>> On Feb 16, 2012 5:14 PM, "John Rose"<john.r.rose at oracle.com
>>> <mailto:john.r.rose at oracle.com**>>  wrote:
>>>
>>>     On Feb 16, 2012, at 1:59 PM, Vitaly Davidovich wrote:
>>>
>>>      I think one problem with them is that they count towards the
>>>>     inlining budget since their bytecodes still take up space.  Not
>>>>     sure if newer C1/C2 compiler builds are "smarter" about this nowadays.
>>>>
>>>
>>>     Optimized object code has (probably) no trace of the assertions
>>>     themselves, but as Vitaly said, they perturb the inlining budget.
>>>       Larger methods have a tendency to "discourage" the inliner from
>>>     inlining, causing more out-of-line calls and a rough net slowdown.
>>>       Currently, the non-executed bytecodes for assertions (which can be
>>>     arbitrarily complex) make methods look bigger than they really are.
>>>       This is (IMO) a bug in the inlining heuristics, which should be
>>>     fixed by examining inlining candidates with a little more care.
>>>       Since the escape analysis does a similar method summarization,
>>>     there isn't necessarily even a need for an extra pass over the methods.
>>>
>>>     -- John
>>>
>>>