[
https://issues.apache.org/jira/browse/HBASE-15785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277347#comment-15277347
]
stack commented on HBASE-15785:
-------------------------------
The patch looks good. The idea is since we allocate the array in constructor
and it does not change thereafter, it is safe to do away with the locks since
we always duplicate and then set limit and position on duplicate? dup and slice
are thread safe you think? Good on you [~anoop.hbase]
> Unnecessary lock in ByteBufferArray#asSubByteBuff
> -------------------------------------------------
>
> Key: HBASE-15785
> URL: https://issues.apache.org/jira/browse/HBASE-15785
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver, Scanners
> Affects Versions: 2.0.0
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-15785.patch, HBASE-15785_V2.patch
>
>
> {code}
> Lock lock = locks[i];
> lock.lock();
> try {
> ByteBuffer bb = buffers[i];
> if (i == startBuffer) {
> cnt = bufferSize - startBufferOffset;
> if (cnt > len) cnt = len;
> ByteBuffer dup = bb.duplicate();
> dup.limit(startBufferOffset + cnt).position(startBufferOffset);
> mbb[j] = dup.slice();
> {code}
> In asSubByteBuff, we work on the duplicate BB and set limit and position on
> that.. The locking is not needed here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
