Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-issues@hadoop.apache.org
Date: Thu, 6 Jun 2013 14:23:22 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: hdfs-issues@hadoop.apache.org
Message-ID: <JIRA.12650972.1370375516301.78216.1370528602960@arcas>
In-Reply-To: <JIRA.12650972.1370375516301@arcas>
References: <JIRA.12650972.1370375516301@arcas>
Subject: [jira] [Commented] (HDFS-4879) Add "blocked ArrayList" collection
 to avoid CMS full GCs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HDFS-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13677056#comment-13677056 ] 

Daryn Sharp commented on HDFS-4879:
-----------------------------------

I think this is a great change, but agree that ChunkedArrayList should ideally be a full-fledged list.  We may find this list implementation to be useful in other places, which is a benefit over using an actual linked list.

Comments/suggestions:
* Default ctor should invoke the ctor with capacity/size to avoid code duplication.
* Consider avoiding need to compute size by tracking it via add/remove?  This would simplify isEmpty() to size == 0.
* Consider removing multiple calls to addChunk() to seed the main list by folding the logic into add?  It could add a new chunk if the list is either empty, or the existing full chunk logic.
* Why does each additional chunk's capacity quadruple?  If necessary, it would be more understandable to multiple by 4.
                
> Add "blocked ArrayList" collection to avoid CMS full GCs
> --------------------------------------------------------
>
>                 Key: HDFS-4879
>                 URL: https://issues.apache.org/jira/browse/HDFS-4879
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: namenode
>    Affects Versions: 3.0.0, 2.0.4-alpha
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>         Attachments: hdfs-4879.txt, hdfs-4879.txt
>
>
> We recently saw an issue where a large deletion was issued which caused 25M blocks to be collected during {{deleteInternal}}. Currently, the list of collected blocks is an ArrayList, meaning that we had to allocate a contiguous 25M-entry array (~400MB). After a NN has been running for a long amount of time, the old generation may become fragmented such that it's hard to find a 400MB contiguous chunk of heap.
> In general, we should try to design the NN such that the only large objects are long-lived and created at startup time. We can improve this particular case (and perhaps some others) by introducing a new List implementation which is made of a linked list of arrays, each of which is size-limited (eg to 1MB).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira