[ https://issues.apache.org/jira/browse/HBASE-14873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037156#comment-15037156 ]
Hiroshi Ikeda commented on HBASE-14873: --------------------------------------- bq. Why sir? Sorry for my poor expression, I just complained that I prefer no waste. As for Unsafe, this is very subtle. I just found ByteBufferUtils uses Unsafe.getInt etc. with no restriction, but the Oracle implementation uses these methods only if the class variable {{unaligned}} (commented as "Cached unaligned-access capability") is true, which seems to be calculated whether the architecture is i386, x86, amd64, or x86_64. ByteBufferUtils also uses Unsafe for on-heap buffers, but Unsafe uses native methods and it consequently prevents VM optimization, and it might eventually wastes for on-heap buffers in long run. In addition, Oracle seems to plan to remove Unsafe in Java 9. {quote} bq. In other words there are situations where we should intentionally use the right buffer in the right place. Makes sense. I think the places where BBBP have been deployed so far make sense. {quote} I mean, it doesn't make sense that users can switch direct/non-direct buffers to pool (in the 1.3 branch) and developers hesitate to improve code to take advantage of direct/non-direct buffers. bq. This issue that you filed is a dirty bug we need to fix regardless, right? Yes, this is an absolutely serious bug that is always occurred when wrapping a cell block, and that must be fixed in any way, regardless of my complaining :( > 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)