Welcome to Omgili,
Omgili ( Oh My God I Love It ;) is a search engine for discussions. With Omgili you can find answers and solutions, debates, discussions, personal experiences, opinions and more... To learn more about Omgili click here.
This is a complete preview of the discussion as it was indexed by Omgili crawlers. Use this preview if the original discussion is unavailable.
Click here to view the original discussion.
[http://forums.yourkit.com/view...]
Click here to search for discussions with Omgili discussions search engine.
 |
YourKit Java Profiler and .NET Profiler Forums :: View topic - Why are Class objects and ClassLoader object again roots?
I reported this issue earlier (on YK 3.1) and it was solved in YK 4.0, see http://forums.yourkit.com/viewtopic.php?t=93, in 4.5 it now seems to have reappeared.
I am using 4.5 build 640 at the moment under JDK 1.5.0_04.
I am trying to solve memory problems in an environment that makes loads of ClassLoaders.
Somehow they don't get GCed.
I would like YK to tell me where the references are that prevents them from be GCed.
YK 4.0 used to do that fine, but 4.5 now reports all ClassLoaders as roots and hence no paths to roots are reported.
I can not use 4.0 because my heap is too big, YK crashes when saving the memory snapshot.
I was very happy to find out that 4.5 saves my snapshots without crashing.
Now I discovered that an old bug has returned.
|
|
Hi,
You are absolutely right, ClassLoaders are not always roots, and only those ClassLoaders are marked as roots that are explicitly reported by JVM as roots (same for Classes - only Classes loaded by system class loader are roots, others are retained by respective loaders).
What kind of roots are they, i.e.
What is shown in [ ] for those objects?
Do you use JVMTI or JVMPI (I'm asking because JVMPI is still available on Java 5.0)?
How big is the snapshot?
If you could upload it to our ftp, it would be easier to find out what the problem is.
Best regards,
Anton
|
|
|
Hi Anton,
They are [Unknown] roots.
I am using -agentlib:yjpagent, that would make it JVMTI, right?
My snapshot is about 250k, I can upload it, no problem, just give me the details of the ftp server.
Regards,
Tom
|
|
Quote: : I am using -agentlib:yjpagent, that would make it JVMTI, right?
Absolutely.
This kind of root is explicitly reported to the profiler by the JVM.
I'm consulting now what this can mean.
I'll post here further info as soon as I get it.
Since we know the roots are of that kind, there's no need to upload the snapshot, because it cannot give addtional information in this case.
|
|
|
Eagerly awaiting your findings....
Thanks for the quick reply!
Tom
|
|
|
I just saw that the snapshot is 250M (not k), hmmm glad you don't need it (although I could have got it to you, if we waited a little).
|
|
Anton,
I am afraid that this is not an easy one.
I did some digging and hit some bugs in the sun database that might be related:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5033614
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4957990The decriptions don't make me happy
Tom
|
|
Hi,
Yes, these issues are possibly related.
I'll ask Sun engineer whether they are indeed related.
From my recent converstation with the Sun engineer, this kind of root have: system class loader (as far as I can understand this is not your case, because you have your own loaders marked with this kind of root, not the system one), and some pre-loaded exception-related stuff (I beleive this is also not related to your class loaders).
So most likely this is issue is a bug in JVM.
Could you please do the following:
1.
Open that problematic snapshot.
2.
"Memory | GC Roots"
3.
Open "Unknown" node
4.
Ctrl+S to save the page as HTML
The Sun contact has said the list of roots of this kind should help to identify the problem.
Also, I have looked into the Sun bugs that you have mentioned.
If I'm not mistaken, this is a problem of server VM.
Could you also please try to add "-client" to see if it makes any difference.
Best regards,
Anton
|
|
|
Hi,
(I'm not sure whether you have received the answer to your recent private message regarding where to send the requested html dump, so I'm repeating it here)
Could you please send the html to anton at yourkit com
Best regards,
Anton
|
|
They are on their way, Anton...
(probably arrived by now )
I found some other bits of info that is interresting to people with ClassLoader problems: http://www.szegedi.org/articles/memleak3.html is worth reading, as well as the related http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6232010.
I also found a way of getting around this "Unknown" problem: I use JDK 1.4.2_09 with -client and -Xrunyjpagent and YK 4.5.
For me that gives propper dependencies and I was able to dig out the bogus references.
Hope this info is useful.
Tom
|
|
Hi,
Here is an explanation, suggested by Sun engineer, of why could the class loaders by marked as Unknown roots:
"During class loading the JVM puts a temporary placeholder in the
system dictionary.
This is used to detect linkage errors such as
ClassCircularityError.
These temporary placeholders are strong roots for
the purposes of garbage collection so they are reported by JVMTI too.
These are two objects associated with each placeholder - a symbol object
(which is not a java-level object and thus not visible to JVMTI agents)
and the class loader object.
So looking at the screen-shots it looks
like <YourCustomClassLoader>
Is in the process of
loading a number of classes at the time that the heap iteration took
place."
So, according to this explanation, it is correct that the loaders can be roots if at the moment of snapshoting they are in process of loading classes.
Best regards,
Anton
|
|
Hi Anton,
Thanks for the explanation, but I am afraid that it is not that easy.
I can not imagine any scenario where all 27 custom ClassLoaders are simultaniously loading classes.
I did some testing which gives results that supports this.
Let me elleborate:
In the mean time (with JVMPI) I found the references that kept my ClassLoaders from being GCed.
I added code to remove them or weaken them.
Now my custom ClassLoaders are correctly GCed.
With this corrected code I ran a number of tests (all with JDK1.5_04 and -client) with the following result:
JVMTI -Xmx100m -XXMaxPermSize=60m OutOfMemory Permgen space
JVMTI -Xmx200m -XXMaxPermSize=120m OutOfMemory Permgen space
JVMPI -Xmx100m -XXMaxPermSize=60m no problems
When I make a dump with JVMTI in YK I get roots marked Other (in the latest YK 4.5 at least, this used to be Unknown).
Among these roots there are a lot of my custom ClassLoaders.
When I make a dump with JVMPI in YK I get no Other roots at all.
I also put some instrumentation in my code that keep weak links to my ClassLoaders.
This shows that under JVMPI they are GCed, but under JVMTI they are not.
My conclusion is that there seems to be a bug in the JVMTI handling code.
What is your oppinion?
Regards,
Tom
|
|
Hi Tom,
Your complains seem very reasonable.
I'll ping them to Sun Because I'm not a developer of JVM internals, I have to depend on Sun's explantions.
Let's see what will be their answer.
Best regards,
Anton
|
|
I'm seeing the same problem with YK 4.5 EAP 650.
How to reproduce:
Take Tomcat 5.5.9, take an empty spring webapp, i.e.
Only a dispatcher servlet in web.xml with an empty WEB-INF/dispatcher-servlet.xml.
Do periodic reloads with /managager/reload?path=/contextpath.
Works fine.
If you start with -agentpath:...\ypjagent.dll, the VM will run out of PermGen space after a number of reloads.
The catalina webapp classloaders show up as [other] roots.
Env:
EAP 650
JDK 1.5.0_04 on XP SP 2
Spring 1.2.2
Tomcat 5.5.9 with commons logging 1.5a (weakly references classloaders)
Can send the webapp on request.
|
|
|
Hi,
Yes, it would be great if you send the web app to reproduce the problem.
Please upload ZIPped stuff to our FTP server
Here is connection parameters:
ftp://194.24.241.196
user: ftp
empty password
Best regards,
Anton
|
|
|
|