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 "Gopal V (JIRA)" <ji...@apache.org> on 2014/04/16 23:18:14 UTC

[jira] [Updated] (HADOOP-10513) ReflectionUtils::CONSTRUCTOR_CACHE leaks class loaders

     [ https://issues.apache.org/jira/browse/HADOOP-10513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gopal V updated HADOOP-10513:
-----------------------------

    Attachment: class-loader-leak.png

> ReflectionUtils::CONSTRUCTOR_CACHE leaks class loaders
> ------------------------------------------------------
>
>                 Key: HADOOP-10513
>                 URL: https://issues.apache.org/jira/browse/HADOOP-10513
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: util
>    Affects Versions: 2.4.0
>            Reporter: Gopal V
>              Labels: leak, permgen
>         Attachments: class-loader-leak.png
>
>
> Any code which uses custom class-loaders needs to be aware of the ReflectionUtils::CONSTRUCTOR_CACHE 
> {code}
>  /** 
>    * Cache of constructors for each class. Pins the classes so they
>    * can't be garbage collected until ReflectionUtils can be collected.
>    */
>   private static final Map<Class<?>, Constructor<?>> CONSTRUCTOR_CACHE = 
>     new ConcurrentHashMap<Class<?>, Constructor<?>>();
> {code}
> This is not a problem when using only 1 AppClassLoader.
> But in cases where the application uses multiple classloaders (to isolate UDFs), this holds onto class references and their associated class loaders by ref (& that leaks all the statics).
> The clear method for this cache is unfortunately marked only for testing.
> {code}
>   // methods to support testing
>   static void clearCache() {
>     CONSTRUCTOR_CACHE.clear();
>   }
> {code}
> The cache shows up as the only reference for the class loaders.
> !class-loader-leak.png!



--
This message was sent by Atlassian JIRA
(v6.2#6252)