[
https://issues.apache.org/jira/browse/HBASE-20716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524287#comment-16524287
]
stack commented on HBASE-20716:
-------------------------------
bq. Is polymorphic dispatch really faster than a final boolean conditional?
Not sure how the question relates.
We currently have a boolean check and then a static dispatch ("invokestatic")
to do unsafe all over our code. The idea is to see if we can do away with
checking the boolean everywhere and instead do it once in a static block on
startup and based off the findings, insert into a static the class to use doing
unsafe going forward; thereafter we could just static dispatch w/o boolean
check. We actually do this already in one of our paths to unsafe (We have more
than one route to unsafe. I'd think that there should be one only -- where this
issue began).
I think we may see savings here on hot paths; in size and so perf. Would be
sweet if [~awked06]'s jmh'ing bore out the supposition.
> Unsafe access cleanup
> ---------------------
>
> Key: HBASE-20716
> URL: https://issues.apache.org/jira/browse/HBASE-20716
> Project: HBase
> Issue Type: Improvement
> Components: Performance
> Reporter: stack
> Priority: Critical
> Labels: beginner
> Attachments: Screen Shot 2018-06-26 at 11.37.49 AM.png
>
>
> We have two means of getting at unsafe; UnsafeAccess and then internal to the
> Bytes class. They are effectively doing the same thing. We should have one
> avenue to Unsafe only.
> Many of our paths to Unsafe via UnsafeAccess traverse flags to check if
> access is available, if it is aligned and the order in which words are
> written on the machine. Each check costs -- especially if done millions of
> times a second -- and on occasion adds bloat in hot code paths. The unsafe
> access inside Bytes checks on startup what the machine is capable off and
> then does a static assign of the appropriate class-to-use from there on out.
> UnsafeAccess does not do this running the checks everytime. Would be good to
> have the Bytes behavior pervasive.
> The benefit of one access to Unsafe only is plain. The benefits we gain
> removing checks will be harder to measure though should be plain when you
> disassemble a hot-path; in a (very) rare case, the saved byte codes could be
> the difference between inlining or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
