Memory leak in Parallel class loading
Bernd Eckenfels
ecki at zusammenkunft.net
Mon Jul 28 19:29:33 UTC 2014
Hello,
do you mean "instances" as in Objects (with the type of your class), or
do you mean instances of the class object. In the later case, are those
all of the same class loader?
If you look at the Heap with MAT, have a look at the incoming
references and the path to the GC root of that CHM. I would suspect it
is something else than the class loader locks.
Greetings
Bernd
Am Mon, 28 Jul 2014 09:01:21
+0000 schrieb "Vasudevan, Sattish" <savasudevan at ebay.com>:
> Hi team,
>
> We encountered a memory leak issue while testing one of our apps.
> When probed the heap dump using MAT, we found 6500 instances of our
> class loaded by org.jboss.modules.ModuleClassLoader occupy 45% of our
> heap size.
>
> We also noticed that reference tree ends in
> java.util.concurrent.ConcurrentHashMap.
>
> >From the above details, the issue seems to be related parallel class
> >loading introduced in Java 7.Java 7 introduced support for parallel
> >classloading.
>
> http://openjdk.java.net/groups/core-libs/ClassLoaderProposal.html
>
> The solution for parallel classloading was to add to each class
> loader a ConcurrentHashMap, referenced through a new field,
> parallelLockMap.
>
> This contains a mapping from class names to Objects to use as a
> classloading lock for that class name.
>
> Want to know is their way by which we can disable parallel class
> loading to confirm on the leak suspect. We use oracle jdk 1.7 Update
> 45.
>
> Thanks
>
> Sattish.
>
>
>
>
More information about the hotspot-gc-use
mailing list