[
https://issues.apache.org/jira/browse/CASSANDRA-9472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106293#comment-15106293
]
Stefania commented on CASSANDRA-9472:
-------------------------------------
Hi [~benedict], thank you for your review.
bq. 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.
I agree that a virtual method is unnecessarily costly. I think I went down the
route of storing the information in {{AbstractBTreeRow}} but I stopped when I
encountered the static methods. If you can pull it off (or any other more
efficient way to store this information) I am definitely OK with it.
bq. 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.
This should be fine, I've verified that we can still run {{NativeCellTest}}
with the debugger and with no adverse effect.
> 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)
