[jira] [Updated] (GEODE-982) Remove unused MemoryChunk classes and make need for memory address more clear

["Sai Boorlagadda (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sai Boorlagadda updated GEODE-982:
----------------------------------
    Summary: Remove unused MemoryChunk classes and make need for memory address more clear  (was: Remove used MemoryChunk classes and make need for memory address more clear)

> 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
>
> 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)