cost of Java "assert" when disabled?

[Ion Ionascu]

Hi Vitaly,


There are command line arguments which control the behavior of the inlining
process (see
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html-
e.g. XX:MaxInlineSize).


Regards,
Ion

www.ionionascu.eu


On Fri, Feb 17, 2012 at 2:37 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:

> 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/c7fece24/attachment.html