[
https://issues.apache.org/jira/browse/HADOOP-11223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185990#comment-14185990
]
Gopal V commented on HADOOP-11223:
----------------------------------
Yes, that's the whole idea. This is merely from a JVM startup point of view.
I'm not sure it is possible to make it immutable at this point, since it is
used both during daemon runtime and job configuration.
In the former mode, Configuration has more intimate problems with multiple
threads & mutability, thanks to addDefaultResources and the internal registry.
> Offer a read-only conf alternative to new Configuration()
> ---------------------------------------------------------
>
> Key: HADOOP-11223
> URL: https://issues.apache.org/jira/browse/HADOOP-11223
> Project: Hadoop Common
> Issue Type: Bug
> Components: conf
> Reporter: Gopal V
> Labels: Performance
>
> new Configuration() is called from several static blocks across Hadoop.
> This is incredibly inefficient, since each one of those involves primarily
> XML parsing at a point where the JIT won't be triggered & interpreter mode is
> essentially forced on the JVM.
> The alternate solution would be to offer a {{Configuration::getDefault()}}
> alternative which disallows any modifications.
> At the very least, such a method would need to be called from
> # org.apache.hadoop.io.nativeio.NativeIO::<clinit>()
> # org.apache.hadoop.security.SecurityUtil::<clinit>()
> # org.apache.hadoop.yarn.factory.providers.RecordFactoryProvider::<clinit>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
