[jira] [Resolved] (LANG-1218) EqualsBuilder.append(Object,Object) is too big to be inlined, which prevents whole builder to be scalarized

["Gary Gregory (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LANG-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Gregory resolved LANG-1218.
--------------------------------
       Resolution: Fixed
    Fix Version/s: 3.5

In Git master.

> EqualsBuilder.append(Object,Object) is too big to be inlined, which prevents whole builder to be scalarized
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: LANG-1218
>                 URL: https://issues.apache.org/jira/browse/LANG-1218
>             Project: Commons Lang
>          Issue Type: Improvement
>          Components: lang.builder.*
>    Affects Versions: 3.4
>            Reporter: Ruslan Cheremin
>             Fix For: 3.5
>
>
> Method EqualsBuilder.append(Object,Object) is 327 bc long, while current JIT hot methods inlining threshold (-XX:FreqInlineSize) = 325. Because of this, .append(Object,Object) is not inlined: with -XX:+PrintInlining -XX:+PrintCompilation following messages could be seen
> {noformat}
> ....
>   @ 13   o.a.c.l.b.EqualsBuilder::append (327 bytes)  hot method too big 
> ....
> {noformat}
> Fail of inlining, by itself, is not so bad -- just a bit penalty to performance. But crucial thing here: without all method being inlined Escape Analysis also fails to trace Builder instance lifespan, and fails to prove it NoEscape. This, in turn, leads EqualsBuilder to be really allocated on heap.
> The funny thing here is: with .append(O,O) being just 2-3 bytecodes smaller, most of EqualsBuilder usage scenarios will be scalarized



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)