cost of Java "assert" when disabled?

[Vitaly Davidovich]

Yes I know (hence I said 35 is default) but wanted to know if there
actually is any dynamic adjustment for hot methods - I don't think there is
but wanted to double check.

Thanks

Sent from my phone
On Feb 17, 2012 9:44 AM, "Ion Ionascu" <ionionascu at gmail.com> wrote:

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