Ruslan Cheremin created LANG-1218:
-------------------------------------
Summary: 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)