[
https://issues.apache.org/jira/browse/HBASE-14873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035127#comment-15035127
]
Hiroshi Ikeda commented on HBASE-14873:
---------------------------------------
To tell the truth I didn't expect to be agreed with the V2 path. I don't grasp
the choice even though there is a way to waste no direct buffer.
BTW, once again, the Oracle implementation does a little more things than
ByteBufferUtils.copyFromBufferToArray. DirectBuffer's override method calls
Unsafe's copyMemory under the limit Bits.UNSAFE_COPY_THRESHOLD, which has been
introduced for scaling well, according to google. How copyFromBufferToArray can
omit the logic? Another thing I should mention is that copyFromBufferToArray is
forced to use one-by-one copy for the other VM implementations, which is an
almost bug.
{quote}
... so BBBP may not be generally applicable. That is what you are thinking?
{quote}
>From the viewpoint of managing, direct buffers use off-heap and it is said
>that creating their objects is heavy, and strongly keeping them in a pool is
>well reasonable. I guess reallocating direct buffers also might cause
>fragmentation in off-heap area. On the other hand, creating an instance of
>non-direct buffer seems much cheaper than retrieving it from the pool, and
>reusing them is only for reducing GC frequency. Once GC is occurred we should
>drop them in the pool, or GC's copying them between young generation causes a
>complete meaningless overhead, in addition to imposing memory usage.
>From the viewpoint of usage, in practice it is sometimes inevitable to use an
>byte array because of some API, and the possibility of using a direct buffer
>imposes labor and time to implement and overhead. On the other hand, using a
>non-direct buffer for socket channels potentially causes problems. In other
>words there are situations where we should intentionally use the right buffer
>in the right place.
> Problems around BoundedByteBufferPool providing direct buffers
> --------------------------------------------------------------
>
> Key: HBASE-14873
> URL: https://issues.apache.org/jira/browse/HBASE-14873
> Project: HBase
> Issue Type: Bug
> Reporter: Hiroshi Ikeda
> Assignee: Hiroshi Ikeda
> Attachments: HBASE-14873-V2.patch, HBASE-14873.patch,
> HBASE-14873.patch, HBASE-14873.patch
>
>
> HBASE-13819 made BoundedByteBufferPool provide direct buffers.
> See RpcServer.java:
> {code}
> ...
> class Call implements RpcCallContext {
> protected synchronized void setResponse(...) {
> ...
> this.cellBlock = ipcUtil.buildCellBlock(..., reservoir);
> ...
> bc = new BufferChain(..., this.cellBlock);
> if (connection.useWrap) {
> bc = wrapWithSasl(bc);
> }
> ...
> private BufferChain wrapWithSasl(BufferChain bc) throws IOException {
> ...
> byte[] responseBytes = bc.getBytes();
> ...
> {code}
> {{cellBlock}} is expected to be a direct buffer retrieved from {{reservoir}}
> (but not always), and {{bc}} may be composed of both direct and non-direct
> buffers.
> And then, see BufferChain.java:
> {code}
> byte [] getBytes() {
> ...
> for (ByteBuffer bb: this.buffers) {
> System.arraycopy(bb.array(), ...);
> {code}
> A direct buffer doesn't give its array, and will throw
> UnsupportedOperationException.
> Another problem; {{cellBlock}} is allowed to be a non-direct buffer, and
> after use it will be put to {{reservoir}}, mixing direct and non-direct
> buffers in the pool.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
