cost of Java "assert" when disabled?

Vitaly Davidovich vitalyd at gmail.com
Fri Feb 17 06:37:58 PST 2012


John,

Doing smarter analysis for inlining decisions would be great.  The other
problem today is that people sometimes create "unnecessary" locals with
SuppressWarnings annotation when cleaning up generics usage (this was
discussed during Oracle's warning cleanup day).  I guess more generally,
some locals can be be folded or optimized out in the generated machine
code, but currently can prevent inlining.  Is this something that you guys
are planning on enhancing? You mention that you think it's a bug, but
unclear on whether there's commitment to fixing it. :)

Also, is the (default) 35 bc length fixed or is it adjusted higher for very
hot methods? The perf wiki mentions that inlining decision is made at parse
time, which sounds like it's fixed but just wanted to double check.

Thanks

Sent from my phone
On Feb 16, 2012 5:14 PM, "John Rose" <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20120217/e120243c/attachment.html 


More information about the hotspot-dev mailing list