cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9472) Reintroduce off heap memtables
Date Tue, 19 Jan 2016 06:05:39 GMT


Stefania commented on CASSANDRA-9472:

Hi [~benedict], thank you for your review.

bq. Storing an offheap variable in BTreeRow looks error-prone to maintain, and forwarding
all calls in AbstractBTreeRow to a virtual onHeapCopy is unnecessarily costly for objects
that never are offheap. I think it makes more sense for the AtomicBTreePartition to check
f it stores on/offheap data when answering a query, and to return a suitable iterator that
knows to copy on-heap when necessary - much as it used to, but moved one step outwards so
that it can capture DecoratedKey and staticRow.

I agree that a virtual method is unnecessarily costly. I think I went down the route of storing
the information in {{AbstractBTreeRow}} but I stopped when I encountered the static methods.
If you can pull it off (or any other more efficient way to store this information) I am definitely
OK with it.

bq. As far as segmentation faults on toString when peer == 0, this is only a problem for the
debugger, because we don't call toString() ourselves. I don't mind adding guards, but they
should really throw exceptions since any access to these objects when they've been freed is
unequivocally a bug.

This should be fine, I've verified that we can still run {{NativeCellTest}} with the debugger
and with no adverse effect.

> Reintroduce off heap memtables
> ------------------------------
>                 Key: CASSANDRA-9472
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Stefania
>             Fix For: 3.x
> CASSANDRA-8099 removes off heap memtables. We should reintroduce them ASAP.

This message was sent by Atlassian JIRA

View raw message