[
https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13965465#comment-13965465
]
Jonathan Ellis commented on CASSANDRA-6694:
-------------------------------------------
bq. why we can't have a simple implementation of the cell which has one buffer
+ metadata about component sizes (which could also be encoded) instead of
having buffer per component in the name (if composite) + buffer for value +
long timestamp
I think this is the key question so I want to back out of the Imple rabbit hole
for a minute to address that. This would absolutely simplify things a great
deal in terms of the Allocator design. The problem is that it has a much
bigger impact on the rest of the code, and the consensus from the last ticket
was, "We want to have off-heap as an option, but we want the default to stay
on-heap and change as little as possible." So, I agree that what you are
saying is cleaner but I think we should push it out to 3.0 given the
constraints for 2.1.
> 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)
