hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiroshi Ikeda (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14940) Make our unsafe based ops more safe
Date Tue, 08 Dec 2015 02:13:10 GMT

    [ 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

View raw message