Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] OutOfMemory in PermGen
Hi,
 
I have used the Memory Monitor plugin and figured out the problem.
It seems to be a wrong configuration in the eclipse.ini file. I have filed a bug for the issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=203325
 
Greetings,
Kaloyan

From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Sunday, September 02, 2007 2:51 AM
To: General discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] OutOfMemory in PermGen


> This really needs to be investigated.

First, I assume it's common knowledge, but "older" SunVM's (e.g. 1.5...._07 and lower) are worse at hitting this error than newer ones, such as _09 and above.
(because of bugs in the VM, not a change in the defaults, or anything). So ... which VM are you using?

Second, knowing how much memory is used (or reserved) is hard to know since the algorithm for determining it varies for different platforms, and versions of the VM, I believe.
Similarly, I believe the eclipse.exe itself tweaks the values under certain circumstances.
Therefore, I'd recommend developers specify ALL the relevent values when investigating this issue (if not all the time).
Such as
-Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m
Googling around, I found where, counter to intuition, the physical memory initially required is a funtion of max heap and perm size (not max perm size).

Third, there's a nifty Memory Monitor tool attached to bug 92250
https://bugs.eclipse.org/bugs/show_bug.cgi?id=92250
This tool display perm gen space (and others) so you can watch to see if/when it grows when you wouldn't expect it to.
In short, the first time you execute some function, you'd expect it to grow, since new classes are presumably loaded.
But, if you do the same function over and over again, and the perm gen usage grows each time, then that is a sign of a "leaking" classloader (probably some custom one),
and would deserve a bug against what ever component is most related to that function.

Hope this helps track this down





"Raev, Kaloyan" <kaloyan.raev@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

08/31/2007 11:23 AM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>
To
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject
RE: [wtp-dev] OutOfMemory in PermGen





Hmm,
 
This is very strange. As far as I am aware of the Sun VM, the object heap memory (the one defined by Xmx) and the class definition memory (the one defined by XXMaxPermSize) do not share one and the same area of physical memory. I mean if say you have -Xmx512m and XXMaxPermSize=256m, then you actually say that the VM will consume a maximum of 512+256 MB of physical memory, not maximum of 512 MB, where 256 MB of them is for objects and 256 MB for class definitions.
 
And there are 2 kinds of OutOfMemoryErrors:
  1) when new object cannot be created - there is not enough memory in the object heap. This happens during a construction of new object. In most cases, in Sun VM (at least up to version 1.4) you don't have even a stack trace.
  2) when a class is attempted to be loaded - there is not enough memory in the PermGen. This happens when a Classloader tries to load new class. You have a stack trace in this case (like the one in my mail below) and you have exception message "OutOfMemoryError: PermGen".
 
So, in theory, it looks quite strange to me that if you decrease the PermSize of the VM, then you stop getting OutOfMemory in the PermSize. And, what people try to do in such situation is to _increase_ the PermSize, not _decrease_ it...
 
This really needs to be investigated.
 
Greetings,
Kaloyan

From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter Moogk
Sent: Friday, August 31, 2007 5:28 PM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] OutOfMemory in PermGen


Hi Raev,
    I ran into the same problem while doing my smoke testing as well.  I talked to John Lanuti about this.  He indicated that he usually uses a setting of -Xmx512M -XXMaxPermSize=128m, so I used this setting as well, which stopped the OOM errors from occuring.   This setting actually reduces the Perm size in half, but doubles the other memory setting.   This seemed to work for me.  I'm a bit concerned as well that somewhere along the line a memory leak may have been introduced.  Are there any performance guys out there that could verify whether or not there is a memory leak.  Thanks.


Peter Moogk
Rational Web Services Development
IBM Canada Ltd.
pmoogk@xxxxxxxxxx
D3-353/ENX/8200/MKM
(905) 413-3458

"Raev, Kaloyan" <kaloyan.raev@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

08/31/2007 02:52 AM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>


To
<wtp-dev@xxxxxxxxxxx>
cc
Subject
[wtp-dev] OutOfMemory in PermGen







Hello,

Yesterday, while I was executing the smoke tests on the wtp-sdk-M-2.0.1-20070830145135 build I got OutOfMemoryError: PermGen… 3 times. This means:

1. I execute smoke test steps.
2. OOM is thrown - restart Eclipse.
3. Continue smoke test steps.
4. OOM is thrown - restart Eclipse.
5. Continue smoke test steps.
6. OOM is thrown - restart Eclipse.
7. Finish smoke test scenario.

This is the first time I have ever got OutOfMemory in the PermGen on a pure WTP stack. Reading the eclipse.ini file I see that the MaxPermSize is set to 256M, which is a significant value. While this can be easily worked around by increasing the MaxPermSize value, I am quite anxious what has happened lately that so many classes are loaded. It is just opening few wizards and views that are enough to spent all of the PermGen.

Has anybody else got the same problem?

Which is the bugzilla component where I should report bugs like this one?

Here is an example of the OOM error from my .log file.

!ENTRY org.eclipse.ui 4 0 2007-08-30 21:53:19.434
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.OutOfMemoryError: PermGen space
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(Unknown Source)
      at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:161)
      at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:501)
      at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:471)
      at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:430)
      at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:413)
      at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189)
      at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340)
      at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:408)
      at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369)
      at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357)
      at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.ClassLoader.loadClassInternal(Unknown Source)
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(Unknown Source)
      at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:161)
      at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:501)
      at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:471)
      at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:430)
      at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:413)
      at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189)
      at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340)
      at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:408)
      at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369)
      at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357)
      at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.ClassLoader.loadClassInternal(Unknown Source)
      at org.eclipse.wst.server.ui.internal.view.servers.ServerActionHelper.fillNewContextMenu(ServerActionHelper.java:49)

        at org.eclipse.wst.server.ui.internal.view.servers.ServersView.fillContextMenu(ServersView.java:319)

Greetings,
Kaloyan Raev
Senior Developer
NW C JS TOOLS JEE (BG)
SAP Labs Bulgaria
T +359/2/9157-416
mailto:kaloyan.raev@xxxxxxx
www.sap.com _______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Back to the top