[
https://issues.apache.org/jira/browse/HBASE-14940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046191#comment-15046191
]
Hiroshi Ikeda commented on HBASE-14940:
---------------------------------------
If there is not unaligned capability, when the starting point to read/write is
at an appropriate aligned boundary it seems possible to use Unsafe methods. It
might be tedious to write such code for every method and its effect might be
doubtful, but in the bulk comparison inserting fine reading until reaching an
appropriate aligned boundary might be worth. In the Oracle implementation,
methods to read/write a single data just use the condition "unaligned", but
DirectDirectBuffer.asInt/LongBuffer etc. methods also check the boundary in
order to, I think, prepare effective bulk read/write.
Comparison to true/false in {{if}} conditions is confusing. It is appropriate
to use the operator "!" instead of comparison to false.
FusszyRowFilter might be appropriate to using polymorphism, making it an
abstract class with a static factory method.
> Make our unsafe based ops more safe
> -----------------------------------
>
> Key: HBASE-14940
> URL: https://issues.apache.org/jira/browse/HBASE-14940
> Project: HBase
> Issue Type: Bug
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Attachments: HBASE-14940.patch
>
>
> Thanks for the nice findings [~ikeda]
> This jira solves 3 issues with Unsafe operations and ByteBufferUtils
> 1. We can do sun unsafe based reads and writes iff unsafe package is
> available and underlying platform is having unaligned-access capability. But
> we were missing the second check
> 2. Java NIO is doing a chunk based copy while doing Unsafe copyMemory. The
> max chunk size is 1 MB. This is done for "A limit is imposed to allow for
> safepoint polling during a large copy" as mentioned in comments in Bits.java.
> We are also going to do same way
> 3. In ByteBufferUtils, when Unsafe is not available and ByteBuffers are off
> heap, we were doing byte by byte operation (read/copy). We can avoid this and
> do better way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
