[
https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13972796#comment-13972796
]
Benedict commented on CASSANDRA-6694:
-------------------------------------
bq. the scope is introduce native implementations -as optimized as possible-
Otherwise we need to do a lot more than the changes you are suggesting :)
bq. Also I'm fine if methods in both implementations are going to return
constant values like serializationFlags or isMarkedForDeleted
Well, these are still duplication - it is not clear as a result where the
definition of these behaviours live. If the semantics change in future, it may
introduce errors unnecessarily. Either way equals(), reconcile() and
validateFields() will still be issues. You don't seem to have implemented most
of these methods yet (looks like your code doesn't actually compile). These
methods are each non-trivial amounts of code duplication, equals() especially
so is we optimise it as you want to. CounterCell.diff() will also need to be
duplicated.
But, like I said, I can probably live with all of this if we address the
setPeer() issue. equals() should probably still end up in a shared static
method, at the very least, though.
> Slightly More Off-Heap Memtables
> --------------------------------
>
> Key: CASSANDRA-6694
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6694
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Benedict
> Labels: performance
> Fix For: 2.1 beta2
>
>
> The Off Heap memtables introduced in CASSANDRA-6689 don't go far enough, as
> the on-heap overhead is still very large. It should not be tremendously
> difficult to extend these changes so that we allocate entire Cells off-heap,
> instead of multiple BBs per Cell (with all their associated overhead).
> The goal (if possible) is to reach an overhead of 16-bytes per Cell (plus 4-6
> bytes per cell on average for the btree overhead, for a total overhead of
> around 20-22 bytes). This translates to 8-byte object overhead, 4-byte
> address (we will do alignment tricks like the VM to allow us to address a
> reasonably large memory space, although this trick is unlikely to last us
> forever, at which point we will have to bite the bullet and accept a 24-byte
> per cell overhead), and 4-byte object reference for maintaining our internal
> list of allocations, which is unfortunately necessary since we cannot safely
> (and cheaply) walk the object graph we allocate otherwise, which is necessary
> for (allocation-) compaction and pointer rewriting.
> The ugliest thing here is going to be implementing the various CellName
> instances so that they may be backed by native memory OR heap memory.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
