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

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LANG-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15275525#comment-15275525 ] 

ASF GitHub Bot commented on LANG-1218:
--------------------------------------

GitHub user marschall opened a pull request:

    https://github.com/apache/commons-lang/pull/138

    LANG-1218 EqualsBuilder.append is too large

    EqualsBuilder.append(Object, Object) is 327 bytes which is 2 bytes
    above the default inline limit of 325 of HotSpot (MaxInlineSize). Micro
    benchmarking has shown this can have a significant performance impact.
    Currently EqualsBuilder can be two to three times slower than writing
    the equals method "by hand". Once the method is small enough to be
    inlined EqualsBuilder has more or less the same performance as writing
    the equals method "by hand".
    
    There are different ways to push the method under the the inline limit.
    I decided to factor out the array handing of append(Object, Object)
    into a method. This leaves the body of append(Object, Object) to do
    what I presume is the common case, the non-array case.
    
    Issue: LANG-1218
    https://issues.apache.org/jira/browse/LANG-1218

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/marschall/commons-lang LANG-1218

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/commons-lang/pull/138.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #138
    
----
commit 8558cb2425ae073d1f441176761791f38d687177
Author: Philippe Marschall <ph...@gmail.com>
Date:   2016-05-08T09:03:05Z

    LANG-1218 EqualsBuilder.append is too large
    
    EqualsBuilder.append(Object, Object) is 327 bytes which is 2 bytes
    above the default inline limit of 325 of HotSpot (MaxInlineSize). Micro
    benchmarking has shown this can have a significant performance impact.
    Currently EqualsBuilder can be two to three times slower than writing
    the equals method "by hand". Once the method is small enough to be
    inlined EqualsBuilder has more or less the same performance as writing
    the equals method "by hand".
    
    There are different ways to push the method under the the inline limit.
    I decided to factor out the array handing of append(Object, Object)
    into a method. This leaves the body of append(Object, Object) to do
    what I presume is the common case, the non-array case.
    
    Issue: LANG-1218
    https://issues.apache.org/jira/browse/LANG-1218

----


> 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
>
> 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)