[
https://issues.apache.org/jira/browse/GEODE-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15200443#comment-15200443
]
ASF subversion and git services commented on GEODE-982:
-------------------------------------------------------
Commit aed5e5f6c1bd1f59c1c6323616b45af31d3f748c in incubator-geode's branch
refs/heads/develop from [[email protected]]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=aed5e5f ]
GEODE-982: Fix javadoc issue introduced in fix for GEODE-982
> 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
> Fix For: 1.0.0-incubating.M2
>
>
> 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)
