You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Robert Kanter (JIRA)" <ji...@apache.org> on 2017/10/13 00:10:00 UTC
[jira] [Comment Edited] (HADOOP-14938)
Configuration.updatingResource map should be initialized lazily
[ https://issues.apache.org/jira/browse/HADOOP-14938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202845#comment-16202845 ]
Robert Kanter edited comment on HADOOP-14938 at 10/13/17 12:09 AM:
-------------------------------------------------------------------
Looks good to me. A couple minor comments:
# Can you take care of the checkstyle warnings? Looks to be mostly indenting levels and line length.
#- https://builds.apache.org/job/PreCommit-HADOOP-Build/13487/artifact/patchprocess/diff-checkstyle-hadoop-common-project_hadoop-common.txt
# The [final example of DCL in Java on Wikipedia|https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java] shows an additional tweak that can allegedly improve performance by as much as 25%. I'm hardly an expert on Java memory internals, so what do you think about this?
{code:java}
private volatile Helper helper;
public Helper getHelper() {
Helper result = helper;
if (result == null) {
synchronized(this) {
result = helper;
if (result == null) {
helper = result = new Helper();
}
}
}
return result;
}
{code}
It adds this extra {{result}} variable.
was (Author: rkanter):
Looks good to me. A couple minor comments:
# Can you take care of the checkstyle warnings? Looks to be mostly indenting levels and line length.
#- https://builds.apache.org/job/PreCommit-HADOOP-Build/13487/artifact/patchprocess/diff-checkstyle-hadoop-common-project_hadoop-common.txt
# The [final example of DCL on Wikipedia|https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java] shows an additional tweak that can allegedly improve performance by as much as 25%. I'm hardly an expert on Java memory internals, so what do you think about this?
{code:java}
private volatile Helper helper;
public Helper getHelper() {
Helper result = helper;
if (result == null) {
synchronized(this) {
result = helper;
if (result == null) {
helper = result = new Helper();
}
}
}
return result;
}
{code}
It adds this extra {{result}} variable.
> Configuration.updatingResource map should be initialized lazily
> ---------------------------------------------------------------
>
> Key: HADOOP-14938
> URL: https://issues.apache.org/jira/browse/HADOOP-14938
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Misha Dmitriev
> Assignee: Misha Dmitriev
> Attachments: HADOOP-14938.01.patch, HADOOP-14938.02.patch
>
>
> Using jxray (www.jxray.com), I've analyzed a heap dump of YARN RM running in a big cluster. The tool uncovered several inefficiencies in the RM memory. It turns out that one of the biggest sources of memory waste, responsible for almost 1/4 of used memory, is empty ConcurrentHashMap instances in org.apache.hadoop.conf.Configuration.updatingResource:
> {code}
> 905,551K (24.0%): java.util.concurrent.ConcurrentHashMap: 22118 / 100% of empty 905,551K (24.0%)
> ↖org.apache.hadoop.conf.Configuration.updatingResource
> ↖{j.u.WeakHashMap}.keys
> ↖Java Static org.apache.hadoop.conf.Configuration.REGISTRY
> {code}
> That is, there are 22118 empty ConcurrentHashMaps here, and they collectively waste ~905MB of memory. This is caused by eager initialization of these maps. To address this problem, we should initialize them lazily.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org