geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-982) Remove unused MemoryChunk classes and make need for memory address more clear
Date Tue, 08 Mar 2016 23:53:40 GMT


ASF subversion and git services commented on GEODE-982:

Commit 3087c86f729785ad9fa021f4437d25ca5ef9231d in incubator-geode's branch refs/heads/develop
from [~dschneider]
[;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:
>             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

This message was sent by Atlassian JIRA

View raw message