[
https://issues.apache.org/jira/browse/CASSANDRA-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092608#comment-13092608
]
Yang Yang commented on CASSANDRA-2252:
--------------------------------------
cool, actually after some thought, I think we need to put more care to
utilizing SlabAllocator for counters:
I realized this when u said "only if it's a memtable-related operation", this
would be very true for some temp variable ByteBuffers, which are thrown away
immediately, and hence get relaimed in the new gen GC, and never go into old
gen.
for counters, the column values (which contain the CounterContext) change a
lot, if we assume that the value of each counter is updated 1000 times during
the life time of a memtable before being flushed, then if you look at a
typical 2MB slab allocated out, 99.9% of the buffers it contains are going to
be non-reachable and GC'ed before flushing. so when the 0.1% buffer is
promoted, it occupies 2MB space instead of its actual size, which would be more
waste than the possible fragmentation problem it causes.
so in this case (or, more generally, all cases where update is more often),
using HeapAllocator may be better.
Thanks
Yang
> arena allocation for memtables
> ------------------------------
>
> Key: CASSANDRA-2252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2252
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 1.0
>
> Attachments: 0001-add-MemtableAllocator.txt,
> 0002-add-off-heap-MemtableAllocator-support.txt, 2252-v3.txt, 2252-v4.txt,
> merged-2252.tgz
>
>
> The memtable design practically actively fights Java's GC design. Todd
> Lipcon gave a good explanation over on HBASE-3455.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
