[jira] [Comment Edited] (CASSANDRA-6694) Slightly More Off-Heap Memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983709#comment-13983709 ] Pavel Yaskevich edited comment on CASSANDRA-6694 at 4/28/14 11:29 PM: -- Here is a [new branch|https://github.com/xedin/cassandra/compare/6694-final] with all of the changes from 6694-reorg2 squashed and added a couple of commits to cleanup and remove secondary index getAllocator which is unnecessary right now. I was about to push similar refactoring for memtable pools to my branch, which made review much faster :) I'm +1 on combination of the squashed changes and cleanup which is in my branch, still not sure about CellName implementation in AbstractNativeCell tho, that is not my realm, so it would be nice if [~slebresne] (or somebody as close to that code, if anybody) could take a look... was (Author: xedin): Here is a [new branch|https://github.com/xedin/cassandra/compare/6694-final] with all of the changes from 6694-reorg2 squashed and added a couple of commits to cleanup and remove secondary index getAllocator which is unnecessary right now. I was about to push similar refactoring for memtable pools to my branch, which made review much faster :) I'm +1 on combination of the squashed changes and cleanup which is in my branch, still not sure about CellName implementation in AbstractNativeCell tho, that is not my realm, so it would be nice if Sylvain (or somebody as close to that code, if anybody) could take a look... 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)
[jira] [Comment Edited] (CASSANDRA-6694) Slightly More Off-Heap Memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13981434#comment-13981434 ] Pavel Yaskevich edited comment on CASSANDRA-6694 at 4/25/14 8:49 PM: - 1-2, 5-7 I will address once the main functionality is settled. bq. AbstractCell.localCopy(..MemtableAllocator) needs to be overridden; as it is you'll always get a regular Cell back Good catch, I forgot to change that before I pushed. Have amended it to the original allocator commit and force pushed to my branch, so it's available. bq. You're still using static method implementations, it looks like? Cell.diff and Cell.reconcile Yes, just two of them, as I mentioned earlier, for the CounterCell because it has to return BufferCounterCell, no point of copying those methods for now. was (Author: xedin): 1-2, 5-7 I will address once the main functionality is settled. bq. AbstractCell.localCopy(..MemtableAllocator) needs to be overridden; as it is you'll always get a regular Cell back Good catch, I forgot to change that before I pushed. Have amended it to the original allocator commit and force pushed to my branch, so it's available. 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)
[jira] [Comment Edited] (CASSANDRA-6694) Slightly More Off-Heap Memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973435#comment-13973435 ] Pavel Yaskevich edited comment on CASSANDRA-6694 at 4/17/14 9:29 PM: - Regarding hashCode that's what we do, I do it in AbstractCell now, Benedict does it in both BufferCell and NativeCell. was (Author: xedin): Regarding, the hashCode that's what we do, I do it in AbstractCell now, Benedict does it in both BufferCell and NativeCell. 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)
[jira] [Comment Edited] (CASSANDRA-6694) Slightly More Off-Heap Memtables
[
https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973534#comment-13973534
]
Pavel Yaskevich edited comment on CASSANDRA-6694 at 4/17/14 10:56 PM:
--
Ok, hashCode and setPeer changes are now pushed to the same branch,
AbstractNativeCell is independent of NativeAllocation now because
NativeAllocator returns aligned peer directly, which allows peer field to be
made final in AbstractNativeCell. Also I have pushed set/get logic for data
size associated with the pointer to the NativeAllocator as it's basically it's
metadata, IMO it's a bit cleaner comparing to how that is done in Benedict's
branch where NativeAllocation tracks pointer alignment to size (internalPeer()
\{ return peer + 4; \}) but NativeAllocator takes care of allocating 4
additional bytes to requested size.
was (Author: xedin):
Ok, hashCode and setPeer changes are now pushed to the same branch,
AbstractNativeCell is independent of NativeAllocation now because
NativeAllocator returns aligned peer directly, which allows peer field to be
made final in AbstractNativeCell. Also I have pushed set/get logic for data
size associated with the pointer to the NativeAllocator as it's basically it's
metadata, IMO it's a bit cleaner comparing to how that is done in Benedict's
branch where NativeAllocation tracks pointer alignment to size (internalPeer()
{ return peer + 4; }) but NativeAllocator takes care of allocating 4 additional
bytes to requested size.
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)
[jira] [Comment Edited] (CASSANDRA-6694) Slightly More Off-Heap Memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973582#comment-13973582 ] Benedict edited comment on CASSANDRA-6694 at 4/17/14 11:55 PM: --- The only reason we were assigning a size in NativeAllocator was to support moving the peer around (in which case you need to know how much memory you're copying). NativeAllocation assuming it has (i.e. _being defined as having_) a size prefix is fine when it is tightly coupled with NativeAllocator (like it is in my branch) - but once you have it as a final field in another object, NativeAllocator should simply have no say in the matter. It never needs to know the size of the allocation, so we should just redefine what our AbstractNativeCell considers to be its size in its sizeOf() calculation, and have the NativeAllocator use that unadulterated value. was (Author: benedict): The only reason it was happening in NativeAllocator was to support moving the peer around (so you need to know how much memory you're copying). NativeAllocation assuming it has (i.e. _being defined as having_) a size prefix is fine when it is tightly coupled with NativeAllocator (like it is in my branch) - but once you have it as a final field in another object, NativeAllocator should simply have no say in the matter. It never needs to know the size of the allocation, so we should just redefine what our AbstractNativeCell considers to be its size in its sizeOf() calculation. 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)
[jira] [Comment Edited] (CASSANDRA-6694) Slightly More Off-Heap Memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973633#comment-13973633 ] Benedict edited comment on CASSANDRA-6694 at 4/18/14 12:36 AM: --- Thanks. Although it looks like you haven't updated any of the offsets to work with the new layout? As to the other changes you've made: I do not like the pollution of PoolAllocator with supportsNative() and allocateNative(). Since this branch is supposed to be pushing idiomatic Java usage, let's stick to using interfaces for specialisation since we can. was (Author: benedict): Thanks. Although it looks like you haven't updated any of the offsets to work with the new layout? As to the other changes you've made: I do not like the pollution of PoolAllocator with supportsNative(). Since this branch is supposed to be pushing idiomatic Java usage, let's stick to using interfaces for specialisation since we can. 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)
[jira] [Comment Edited] (CASSANDRA-6694) Slightly More Off-Heap Memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13972205#comment-13972205 ] Pavel Yaskevich edited comment on CASSANDRA-6694 at 4/17/14 1:45 AM: - So here is the [branch|https://github.com/xedin/cassandra/compare/CASSANDRA-6694] which implements my idea of how to get rid of the Impl classes for Cell (+ does optimized updateDigest for both Cell implementations and couple of other things), I left DecoratedKey alone for now, work not fully complete yet but only couple on nit things are missing - I need to change couple of places to use CFMetaData and clone native cells so I decided not to do it if we are not going to go with that code. Regarding [~benedict]'s reorg branch I found couple of problems: # internalGetLong(long, long) is actually meant to be internalSetLong(long, long) in AbstractMemory; # CounterUpdateCell should be BufferCounterUpdateCell as it extends BufferCell # CounterUpdateCell interface is missing as well as NativeCounterUpdateCell implementation to match it. # in e.g. NativeExpiringCell there is no need to declare that it implements CellName as NativeCell already does it. # Impl classes extends another Impl classes which doesn't make much sense as all of the methods are static. bq. 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. When taken out of context like that it doesn't really make sense but what I meant, there are situation where we don't really need to get BB from the CellName but can transfer bytes directly (especially for the native cell implementations). bq. I construct it using unsafe, which skips all constructors. So there is no synchronization or PhantomReference creation. Right, we should be good there, my bad. was (Author: xedin): So here is the [branch|https://github.com/xedin/cassandra/compare/CASSANDRA-6694] which implements my idea of how to get rid of the Impl classes for Cell (+ does optimized updateDigest for both Cell implementations and couple of other things), I left DecoratedKey alone for now, work not fully complete yet but only couple on nit things are missing - I need to change couple of places to use CFMetaData and clone native cells so I decided not to do it if we are not going to go with that code. Regarding [~benedict]'s reorg branch I found couple of problems: # internalGetLong(long, long) is actually meant to be internalSetLong(long, long) in AbstractMemory; # CounterUpdateCell should be BufferCounterUpdateCell as it extends BufferCell # CounterUpdateCell interface is missing as well as NativeCounterUpdateCell implementation to match it. bq. 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. When taken out of context like that it doesn't really make sense but what I meant, there are situation where we don't really need to get BB from the CellName but can transfer bytes directly (especially for the native cell implementations). bq. I construct it using unsafe, which skips all constructors. So there is no synchronization or PhantomReference creation. Right, we should be good there, my bad. 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
[jira] [Comment Edited] (CASSANDRA-6694) Slightly More Off-Heap Memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958166#comment-13958166 ] Benedict edited comment on CASSANDRA-6694 at 4/2/14 10:38 PM: -- Sure. There are now four main concepts that interact in various ways: ByteBufferAllocator, Pool PoolAllocator, ByteBufferPool.Allocator (and its implementors) and NativeAllocator # ByteBufferAllocator, as the name suggests, is a straightforward abstraction for the allocation/cloning of NIO ByteBuffers. It does not directly support any concept of pooling, nor understand the use of OpOrder for write guarding. # Pool and PoolAllocator are now independent of any concept of *what* they allocate - they simply manage the idea of the memory resources, and leave the actual allocation to the implementing class # ByteBufferPool.Allocator is the combination of PoolAllocator and BBA, although it itself isn't a BBA - it constructs a context BBA when given a writeOp that is guarding the allocation. This helps to keep the concept of write guarded pooled allocations cleanly separated from simple BBA allocations, whilst using the same code paths. Note that BBP.A is _abstract_ and is implemented by SlabAllocator and HeapPool.Allocator. # NativeAllocator is, by contrast, the extension of PoolAllocator that supports native allocations - that is, any object that extends NativeAllocation. was (Author: benedict): Sure. There are now four main concepts that interact in various ways: ByteBufferAllocator, Pool PoolAllocator, ByteBufferPool.Allocator (and its implementors) and NativeAllocator # ByteBufferAllocator, as the name suggests, is a straightforward abstraction for the allocation/cloning of NIO ByteBuffers. It does not directly support any concept of pooling, nor understand the use of OpOrder for write guarding. # Pool and PoolAllocator are now independent of any concept of *what* they allocate - they simply manage the idea of the memory resources, and leave the actual allocation to the implementing class # ByteBufferPool.Allocator is the combination of PoolAllocator and BBA, although it itself isn't a BBA - it constructs a context BBA when given a writeOp that is guarding the allocation. This helps to keep the concept of write guarded pooled allocations cleanly separated from simple BBA allocations, whilst using the same code paths. Note that BBP.A is _abstract_ and is implemented by SlabAllocator and HeapPool.Allocator. We might consider renaming SlabAllocator to HeapSlabAllocator to keep naming consistent and help clarity. # NativeAllocator is, by contrast, the extension of PoolAllocator that supports native allocations - that is, any object that extends NativeAllocation. 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)
[jira] [Comment Edited] (CASSANDRA-6694) Slightly More Off-Heap Memtables
[ https://issues.apache.org/jira/browse/CASSANDRA-6694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13944357#comment-13944357 ] Benedict edited comment on CASSANDRA-6694 at 3/23/14 7:05 AM: -- FTR, with a very simple and short performance comparison, simulating writing a lot of small (integer) fields, using cassandra-stress write n=40 -col size=fixed\(4\) n=fixed\(100\), I see a 25% throughput improvement using offheap_objects as the allocator type vs either on/off heap buffers. I would expect to see performance improve further as the length of the test increases, as write amplification takes its toll more rapidly on the heap buffers, but don't intend to test this out much further as it was just for some ball park idea of how much impact it might have. was (Author: benedict): FTR, with a very simple and short performance comparison, simulating writing a lot of small (integer) fields, using cassandra-stress write n=40 -col size=fixed\(4\) n=fixed\(100\), I see a 25% throughput improvement using offheap_objects as the allocator type vs either on/off heap buffers. I should expect to see performance improve further as the length of the test increases, as write amplification takes its toll more rapidly on the heap buffers. 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)
