You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2016/03/11 20:29:39 UTC

[jira] [Comment Edited] (HBASE-15431) A bunch of methods are hot and too big to be inlined

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

Andrew Purtell edited comment on HBASE-15431 at 3/11/16 7:29 PM:
-----------------------------------------------------------------

bq.  After that I no longer see any "hot method too big" messages. But performance actually seemed to be slower. 

This is why you normally shouldn't try to tune inlining heuristics. :-)

bq. Note that almost all interesting methods using during scanning are not inlined.

That's because interesting == nontrivial == big, right? 

bq. But as I said, it's not a trivial quick fix, it's need to rethinking of the structure of this method. 

I will venture the opinion that JVM compiler heuristics are pretty good. However it does make sense to look at methods right on the edge that show up as hot. By all means tinker and see if we can get an improvement after a refactor. It's a bit like prospecting though, you'll have to drill in a bunch of places before striking oil.

Edit: And the payoff you see will depend on and vary between major JVM compiler drops. 7u versus 8u. 8u60 versus earlier versions, etc etc.


was (Author: apurtell):
bq.  After that I no longer see any "hot method too big" messages. But performance actually seemed to be slower. 

This is why you normally shouldn't try to tune inlining heuristics. :-)

bq. Note that almost all interesting methods using during scanning are not inlined.

That's because interesting == nontrivial == big, right? 

bq. But as I said, it's not a trivial quick fix, it's need to rethinking of the structure of this method. 

I will venture the opinion that JVM compiler heuristics are pretty good. However it does make sense to look at methods right on the edge that show up as hot. By all means tinker and see if we can get an improvement after a refactor. It's a bit like prospecting though, you'll have to drill in a bunch of places before striking oil.

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