You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benedict (JIRA)" <ji...@apache.org> on 2016/01/18 12:27:40 UTC
[jira] [Comment Edited] (CASSANDRA-9472) Reintroduce off heap
memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105169#comment-15105169 ]
Benedict edited comment on CASSANDRA-9472 at 1/18/16 11:27 AM:
---------------------------------------------------------------
Thanks for finishing up finding the work [~Stefania].
It looks mostly good, but I would probably modify it a little from its current representation:
* Storing an {{offheap}} variable in {{BTreeRow}} looks error-prone to maintain, and forwarding all calls in {{AbstractBTreeRow}} to a virtual {{onHeapCopy}} is unnecessarily costly for objects that never are offheap. I think it makes more sense for the {{AtomicBTreePartition}} to check f it stores on/offheap data when answering a query, and to return a suitable iterator that knows to copy on-heap when necessary - much as it used to, but moved one step outwards so that it can capture {{DecoratedKey}} and {{staticRow}}
* As far as segmentation faults on {{toString}} when {{peer == 0}}, this is only a problem for the debugger, because we don't call {{toString()}} ourselves. I don't mind adding guards, but they should really throw exceptions since any access to these objects when they've been freed is unequivocally a bug.
Let me know your thoughts (and I'll finish this up, if we're in agreement).
was (Author: benedict):
Thanks for finishing up finding the work [~Stefania].
It looks mostly good, but I would probably modify it a little from its current representation:
* Storing an {{offheap}} variable in {{BTreeRow}} looks error-prone to maintain, and forwarding all calls in {{AbstractBTreeRow}} to a virtual {{onHeapCopy}} is unnecessarily costly for objects that never are offheap. I think it makes more sense for the {{AtomicBTreePartition}} to check f it stores on/offheap data when answering a query, and to return a suitable iterator that knows to copy on-heap when necessary - much as it used to, but moved one step outwards so that it can capture {{DecoratedKey}} and {{staticRow}}
* As far as segmentation faults on {{toString}} when {{peer == 0}}, this is only a problem for the debugger, because we don't call {{toString()}} ourselves. I don't mind adding guards, but they should really throw exceptions since any access to these objects when they've been freed is unequivocally a bug.
Let me know your thoughts.
> Reintroduce off heap memtables
> ------------------------------
>
> Key: CASSANDRA-9472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9472
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Benedict
> Assignee: Stefania
> Fix For: 3.x
>
>
> CASSANDRA-8099 removes off heap memtables. We should reintroduce them ASAP.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)