geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darrel Schneider (JIRA)" <>
Subject [jira] [Assigned] (GEODE-982) Remove unused MemoryChunk classes and make need for memory address more clear
Date Fri, 19 Feb 2016 23:20:18 GMT


Darrel Schneider reassigned GEODE-982:

    Assignee: Darrel Schneider

> 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