cost of Java "assert" when disabled?

[David Holmes]

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
>