[
https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13965481#comment-13965481
]
Jonathan Ellis commented on CASSANDRA-6694:
-------------------------------------------
bq. Can we decide if we actually want to have Cell (and derivatives) as this
patch set proposes (with static Impl static classes which is OOP unfriendly to
say the least) or do something else (question raised back in CASSANDRA-6689)?
If we accept the NativeCell/BufferCell distinction above, then the combination
of optimization and lack of multiple inheritance drives this design or
something like it. Specifically, we want NativeCell to be both a Cell and a
NativeAllocation, so Benedict has (reasonably, IMO) chosen to extend NA and
leave the Cell common methods in a "utility" Impl class. (IMO the "right" OOP
approach would be to extend Cell, making it an Abstract class instead of an
Interface, and have NativeCell have a NA as a field instead of extending it.
But then we're increasing the memory overhead of a NC by almost 50% which
directly impacts our main goal here.)
I can see reasonable alternatives to where exactly the static utility methods
live: put them in the BufferCell classes and have the Native classes reuse them
that way, or put them in a separate class entirely, and I'm okay with either of
those options but I don't really see them as strictly better than the Impl
choice (which has the advantage of "encapsulating" what interface specifically
they deal with, distinct from the Buffer or Native subclasses).
> 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)
