[
https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970603#comment-13970603
]
Benedict commented on CASSANDRA-6694:
-------------------------------------
bq. for now we are allocating BufferCounterCell which allows as to use
CounterCell.Impl.reconcile for both implementations
We only allocate a new object in the case that the reconcile result isn't one
or the other of the original inputs. This object is only incredibly short
lived, and we decided it was easier than passing through the allocator for
reconcile. This may be slightly worse than we'd like as a result of the
different cellname layouts, but that can be smoothed over with time. It's
cleaner in the Memtable +ABC code to keep the pool allocation separate from
this reconcile, and it's small fry compared to the other stuff we're doing on
write of counters.
bq. it would be much better to have native implementations which work with
underlying bytes directly from day one
Agreed that some of these would be nice, however we rarely (if ever) call
these, and as per your comments wrt zero-copy (CASSANDRA-6842), if we aren't
worried about copying the contents, we shouldn't be worried about allocating
temporary objects. Now, there are some methods I would say would be nice to
have native implementations of sooner than later (e.g. updateDigest), but I
don't think they're by any means _essential_. What is going to be *far* more
impactful is CASSANDRA-6755, as this has a reasonably large negative impact on
name lookups (and to a lesser degree slicing) from a memtable record.
That said, some of them would be quite easy to implement. So I'm not totally
opposed to delivering them from day 1, I just wanted this patch set to be
clearly readable and well contained. It's pretty big as it is. I think it would
be nice to put any of these optimisations in a second ticket.
If you're suggesting we drop the Impl hierarchy entirely from this patchset and
just duplicate the methods and optimise, I can maybe get behind that. However
optimising reconcile() and equals() gets ugly quickly if you want to be able to
deal with either side of the equation being one or the other (often we'll
reconcile different kinds, but not always). So we still need a shared
implementation, but one that is capable of detecting the kind of Cell on each
side, and selects the correct version of the method. Leaving very few methods
we'll be optimising in Native*Cell, so most of the code will be duplicated
unnecessarily if we take that route. But I can live with that if the reviewers
can all live with the increased size of the patchset.
bq. name.toByteBuffer() convert data from one representation to another for no
real reason
Why do you say "no real reason"? This is the serialization format, so we have
to convert to it. That's the definition of what toByteBuffer() should return.
We only call it when writing to disk or to the network, and is no different
from the original implementation in that regard. That's not to say with time we
cannot change this, but there's not much we can do yet.
bq. There is another concern related to ... DirectBuffer ... initialization of
that class is synchronized and creates PhantomReference
I construct it using unsafe, which skips all constructors. So there is no
synchronization or PhantomReference creation.
> 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)
