cost of Java "assert" when disabled?

[Vitaly Davidovich]

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.

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.

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
>>
>>