You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/05/18 20:51:12 UTC
[jira] [Commented] (GEODE-1292) Investigate how
FreeListManager.defragment handles chunks larger than 2G
[ https://issues.apache.org/jira/browse/GEODE-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289792#comment-15289792 ]
ASF subversion and git services commented on GEODE-1292:
--------------------------------------------------------
Commit d14af16ae7ed4d52379877e508683b6df05ff5d1 in incubator-geode's branch refs/heads/develop from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=d14af16 ]
GEODE-1292: change defragment to not create fragments > 2G
> Investigate how FreeListManager.defragment handles chunks larger than 2G
> ------------------------------------------------------------------------
>
> Key: GEODE-1292
> URL: https://issues.apache.org/jira/browse/GEODE-1292
> Project: Geode
> Issue Type: Bug
> Components: offheap
> Reporter: Darrel Schneider
> Assignee: Darrel Schneider
> Fix For: 1.0.0-incubating.M3
>
>
> Currently the initial slabs of off-heap memory are always 2G or less in size.
> But if we have two initial slabs that are contiguous in memory what would prevent defragment from unifying them together into a single slab of 4G?
> If it does this we are in trouble because the chunkSize is a 32-bit int and will overflow.
>
> Defragment needs to detect this and just create a chunk of 2G and then start a new one. Or to prevent it from happening we could just check the incoming slabs and throw away a few bytes to keep them from being contiguous.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)