[
https://issues.apache.org/jira/browse/HBASE-15431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15188823#comment-15188823
]
Lars Hofhansl commented on HBASE-15431:
---------------------------------------
bq. Was 1010 enough to get the list of methods inlined?
Yep. The largest is 1006 bytes. After that I no longer see any "hot method too
big" messages. But performance actually seemed to be slower. So maybe this is a
dud...? I looked into breaking up StoreScanner.next(...), it's pretty messy
now, with many exits (continue with the loop, break out of loop, return from
the method with result true, return with false, etc). What we want to do is
breaking up the larger method so that hot code is separate from the not so hot
code. So in StoreScanner.next we'd try to more DONE, DONE_SCAN, maybe XXX_SEEK
code to separate methods. That would allow the more frequent and very hot SKIP
and INCLUDE code paths to be inlined... But as I said, it's not a trivial quick
fix, it's need to rethinking of the structure of this method. Others are
similar.
> A bunch of methods are hot and too big to be inlined
> ----------------------------------------------------
>
> Key: HBASE-15431
> URL: https://issues.apache.org/jira/browse/HBASE-15431
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Attachments: hotMethods.txt
>
>
> I ran HBase with "-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions
> -XX:+PrintInlining" and then looked for "hot method too big" log lines.
> I'll attach a log of those messages.
> I tried to increase -XX:FreqInlineSize to 1010 to inline all these methods
> (as long as they're hot, but actually didn't see any improvement).
> In all cases I primed the JVM to make sure the JVM gets a chance to profile
> the methods and decide whether they're hot or not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
