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