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 Thu, 17 Mar 2016 21:39:33 GMT


ASF subversion and git services commented on GEODE-982:

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

This message was sent by Atlassian JIRA

View raw message