cost of Java "assert" when disabled?
vitalyd at gmail.com
Fri Feb 17 06:48:25 PST 2012
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.
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).
> On Fri, Feb 17, 2012 at 2:37 PM, Vitaly Davidovich <vitalyd at gmail.com>wrote:
>> 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.
>> 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...
More information about the hotspot-dev