[
https://issues.apache.org/jira/browse/HBASE-20716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524111#comment-16524111
]
stack commented on HBASE-20716:
-------------------------------
[~awked06] Nice work. Thank you. Looks like you found a missing 'final'.
I was more interested in saving byte codes. We do these checks all over the
place bulking up our generated byte code. For example, here is
ByteBufferUtils#toShort !Screen Shot 2018-06-26 at 11.37.49 AM.png! See how
this simple method -- repeated below -- does an unsafe check before going into
unsafe rather than just doing the dispatch. It is two instructions every time.
My thought was a refactor so unsafe access used the Bytes class trick of
figuring out if unsafe is available (alignment, endianness, etc.) once at
startup in statics, then we would just be dispatching and not check then
dispatch all over the place. I originally filed this issue when I was sensitive
to method sizes seeing how inlined methods went much faster than those that
were not inlined usually because they were too big.
Perhaps in your JMH'ing, you can see if undoing the check speeds us up at all
(we'd be doing less work if less instructions but perhaps it makes no
difference?). Then, you could see if the check+dispatch was more expensive
than the dispatch that we do with Bytes#LexicographicalComparerHolder. If
savings to be had, then we could go ahead with this method and move all unsafe
access to use the Bytes#LexicographicalComparerHolder trick?
public static short toShort(ByteBuffer buffer, int offset) {
if (UNSAFE_UNALIGNED) {
return UnsafeAccess.toShort(buffer, offset);
} else {
return buffer.getShort(offset);
}
}
> 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)
