[ 
https://issues.apache.org/jira/browse/HDFS-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071222#comment-14071222
 ] 

Kai Zheng commented on HDFS-6709:
---------------------------------

bq. The {{ByteBuffer}} interface should be slower, since it needs to update 
offsets and do boundary checking.
Agree. But it still meets the primary goal here, i.e. putting data off heap.

I'm wondering if using Unsafe can be avoided here or not. There were some 
discussions with Oracle related to this and we were updated that, JDK9 is 
likely to block all accesses to sun.* classes.*. Therefore we might need to 
clean up such calls before that and avoid new ones like here. Regarding Unsafe 
situation, you might look at the following doc (provided by Max from Oracle), 
and give your insights. Thanks.
http://cr.openjdk.java.net/~psandoz/dv14-uk-paul-sandoz-unsafe-the-situation.pdf

> Implement off-heap data structures for NameNode and other HDFS memory 
> optimization
> ----------------------------------------------------------------------------------
>
>                 Key: HDFS-6709
>                 URL: https://issues.apache.org/jira/browse/HDFS-6709
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: namenode
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>         Attachments: HDFS-6709.001.patch
>
>
> We should investigate implementing off-heap data structures for NameNode and 
> other HDFS memory optimization.  These data structures could reduce latency 
> by avoiding the long GC times that occur with large Java heaps.  We could 
> also avoid per-object memory overheads and control memory layout a little bit 
> better.  This also would allow us to use the JVM's "compressed oops" 
> optimization even with really large namespaces, if we could get the Java heap 
> below 32 GB for those cases.  This would provide another performance and 
> memory efficiency boost.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to