[
https://issues.apache.org/jira/browse/GEODE-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15186098#comment-15186098
]
ASF subversion and git services commented on GEODE-982:
-------------------------------------------------------
Commit 3087c86f729785ad9fa021f4437d25ca5ef9231d in incubator-geode's branch
refs/heads/develop from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=3087c86 ]
GEODE-982: refactor off-heap
- removed unused MemoryChunk implementations
- collapsed OffHeapCacheDeserializable into StoredObject
- Added Slab, SlabFactory, SlabImpl, and AddressableMemoryManager.
- collapsed MemoryChunkWithRefCount into StoredObject
- methods that access and modify the data now have Data in their name
- collapsed AddressableStoredObject into StoredObject
- changed product code to use the StoredObject interface
instead of internal class implementations of it
- renamed DataAsAddress to TinyStoredObject
- renamed ObjectChunk to OffHeapStoredObject
- renamed ObjectChunkWithHeapForm to OffHeapStoredObjectWithHeapForm
- renamed allocateChunk to allocateOffHeapStoredObject
- renamed FakeChunk to SearchMarker
- renamed ObjectChunkSlice to OffHeapStoredObjectSlice
- renamed SyncChunkStack to OffHeapStoredObjectAddressStack
- renamed ChunkValueWrapper to OffHeapValueWrapper
> Remove unused MemoryChunk classes and make need for memory address more clear
> -----------------------------------------------------------------------------
>
> Key: GEODE-982
> URL: https://issues.apache.org/jira/browse/GEODE-982
> Project: Geode
> Issue Type: Improvement
> Components: offheap
> Reporter: Darrel Schneider
> Assignee: Darrel Schneider
>
> The current implementations of MemoryChunk include unsafe, byte array, and
> byte buffer. But the product can only use the unsafe implementation. Both the
> byte array and byte buffer do not provide a memory address that can be used.
> They were created for some early performance experimentation but the off-heap
> implementation has since moved on and now requires a MemoryChunk that exposes
> addressable memory.
> The other confusing thing about MemoryChunk it is used for two things:
> 1. a raw slab of memory that just has an address, a size, and can be released.
> 2. a chunk of memory that has an off-heap object header that can be reference
> counted, and can be used to store a java object.
> The current MemoryChunk interface has too much on it for #1 (slabs) and too
> little on it for #2 (chunks). I think it would be helpful to split these up
> into two different interfaces instead of trying to have the common
> MemoryChunk interface they both share.
> It would also be helpful if all the places that used static method to
> read/write memory at a given address used an interface dedicated to that. It
> could be called AddressableMemoryManager. All the "unsafe" code for the
> off-heap implementation should be in the AddressableMemoryManager. We could
> then try alternate implementations of it without needing to change all of our
> other code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
