Community
Participate
Working Groups
In the past we increased PermGen size for the default Eclipse SDK configuration to 256Mb (see "--launcher.XXMaxPermSize 256m" in the config.ini). Those increased PermGen settings are not propagated into Run/Debug configurations unless manually specified in the VM arguments list. As an example of a practical consequence, running Platform UI JUnit tests on Windows 64 bit stack results in "Out of PermGen memory" error about half the time.
The PDE target platform imports default vm arguments into new launch configs. However, the "--launcher.XXMaxPermSize 256m" is not a vm argument. It is a launcher argument. The launcher may add it to the vm (if is recognizes a Sun VM), but it is not listed as a vm argument in the config.ini so PDE doesn't know it is valid. Marking as an enhancement, because to make this work we would need custom code in the target platform to look for this specific argument in the configuration settings and add a custom vm argument (-XX:PermSize=256M).
Needs more investigation as in 4.2 the common workflow of Launch, write a plug-in, launch a hosted workspace, may fail due to permgen.
I don't have a good solution for this. One possibility would be for the target platform to import that specific launcher argument. Then when creating new launch configurations we would put that argument (or a more descriptive argument of our choosing) in the config's program arguments. When launching, we would check for this program argument and then check if we are launching with a Sun VM (or whatever logic the launcher uses). If those checks pass, we would add the permgen argument to the vm arguments. There is no way to cleanly explain this convoluted process to the user. Users have no indication why the argument would be listed in their target platform or their launch configurations. We would be modifying the vm arguments after the user has already set their expected VM arguments in the config. Do we think this issue is critical to promoting 4.2? I have no memory issues launching a second workbench with default settings (on Java 7), but running a test suite is problematic.
I would close this as WONTFIX. Giving the same amount of memory to the launch configs as I give to my IDE can quickly cause out of memory conditions as well. Also, it would look strange if we do it for permGen but not for the "normal" memory (or any other VM args specified for the IDE's VM). People can either set the default VM arguments or give greedy test launches more normal and/or permGen memory.
(In reply to comment #4) > I would close this as WONTFIX. Giving the same amount of memory to the launch > configs as I give to my IDE can quickly cause out of memory conditions as well. > Also, it would look strange if we do it for permGen but not for the "normal" > memory (or any other VM args specified for the IDE's VM). Note that we do import any other VM args from your host's eclipse.ini. The problem here is permgen is by default not set using a vm arg. Instead a launcher argument is used that the launcher may or may not resolve to a vm argument.
(In reply to comment #5) > Note that we do import any other VM args from your host's eclipse.ini. The > problem here is permgen is by default not set using a vm arg. Instead a > launcher argument is used that the launcher may or may not resolve to a vm > argument. Ah, indeed! I guess I never noticed this because I have a very old workspace with old launch configs.
(In reply to comment #3) > Do we think this issue is critical to promoting 4.2? I just got the out-of-memory exception while debugging a problem in the plain Eclipse SDK with no extra bundles installed: !ENTRY org.eclipse.ui 4 0 2012-04-02 11:29:14.818 !MESSAGE Error occurred during status handling Error while logging event loop exception: java.lang.OutOfMemoryError: PermGen space
There are no plans to makes changes here for 3.8/4.2, removing target milestone.
The 'ease' of nested Eclipse is one of many good Eclipse features. It is very important for Modeling applications that develop executable code, but with models being demanding on PermGen they just about never work for users or experts. The only difference is that experts can just curse and try again after struggling with a load of UI lockouts and finding the correct Java VM to kill. Novices really struggle. It is really irresponsible to ship such poor functionality. reply to comment #5) > Note that we do import any other VM args from your host's eclipse.ini. The > problem here is permgen is by default not set using a vm arg. Instead a > launcher argument is used that the launcher may or may not resolve to a vm > argument. Surely this makes it easier. Non-VM arguments can be propagated with less change in behaviour.
(In reply to comment #9) > > Note that we do import any other VM args from your host's eclipse.ini. The > > problem here is permgen is by default not set using a vm arg. Instead a > > launcher argument is used that the launcher may or may not resolve to a vm > > argument. > > Surely this makes it easier. Non-VM arguments can be propagated with less > change in behaviour. This is not the case for nesting Eclipse. The launcher has support for a variety of arguments including the permgen setting. However, the launcher is not used when launching a runtime Eclipse application inside Eclipse, making any arguments we import useless.
I'm afraid that I don't follow. The 'launcher' may have a special narrow meaning to some developers, but to a naive user, the launcher/initiator is what causes the nested Eclipse to run and it is this 'initiator' that needs to be given the appropriate control; just as could apparently be done if the 'launcher' were in use.
(In reply to comment #11) > I'm afraid that I don't follow. The 'launcher' may have a special narrow > meaning to some developers, but to a naive user, the launcher/initiator is what > causes the nested Eclipse to run and it is this 'initiator' that needs to be > given the appropriate control; just as could apparently be done if the > 'launcher' were in use. The launcher is a OS specific application used to launch Eclipse (eclipse.exe, etc.). This application recognizes the --launcher.XXMaxPermSize argument, determines whether the vm being used supports a permgen argument and sets it before starting the vm. http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Flauncher.html When launching inside of Eclipse (Eclipse Runtime Application), the launcher is not used. We start Java/OSGi directly, so the --launcher.XXMaxPermSize argument means nothing to us. Even if we imported it from eclipse.ini and wanted to use it, we would need to duplicate the launcher code that checks for vm support (this may be OS specific as well).
Hi, I work in the Java SE PM team for Oracle. I can't comment on the specifics related to argument passing, and the eclipse launcher, etc. But for what it's worth, we feel your pain WRT to permgen. There is a JEP and plan to remove Permgen for JDK 8 (http://openjdk.java.net/jeps/122) following the ongoing convergence with JRockit and HotSpot. At some point, it may find it's way back to Java 7, but not likely before JDK 8 is released. I realize this doesn't solve your immediate issues, sorry about that.
I tend to feel that the -XX:MaxPermSize argument should be associated more with the Installed JRE and less with a specific launch config. I do see that the Installed JRE Preferences have a "Default VM Arguments" section when editing the JRE. These arguments seem to be applied transparently to launches using that JRE. Perhaps the easiest thing to do would be to provide documentation/guidance on setting up the installed JREs to use these default arguments. As far as setting this as a default, maybe the "Installed JRE" code is in a better position than the "PDE launch" code to determine the vendor and set this arg. (I seem to remember something about actually launching the installed JREs to determine its properties when we first talked about Execution Environment descriptions http://wiki.eclipse.org/Execution_Environment_Descriptions)
*** Bug 370369 has been marked as a duplicate of this bug. ***
I have been experiencing hangs during startup with the latest Luna builds. Absolutely related to PermGen allocation. Let me first state this is on OSX with 16GB Ram and SSD drive and a huge workspace. Here is the interesting thing. When I specify -XX:MaxPermSize and -XX:PermSize I have no problems. When only -XX:MaxPermSize the trouble begins, even if it is -XX:MaxPermSize 1024m. I ran Java VisualVM and saw exactly what was going on. When -XX:PermSize is set to a value larger than needed, the allocated memory is constant (see screenshot #1). When -XX:PermSize is set to a value smaller than needed, the allocated memory is grows as needed (see screenshot #2). When -XX:PermSize is not and needed PermGen increases quickly at startup, the PermGen is not resized fast enough, or in large enough increments, causing a severe hang. Then all of a sudden allocation happens. (see screenshot #3) Manually invoking garbage collection from Java Visual VM sometimes helped Eclipse make it through this launch period. So I have 2 suggestions. #1 Include even a minimum -XX:PermSize in the default launch configuration #2 Manually call garbage collection more often in the platform startup code.
Created attachment 244208 [details] screenshot 1 (XXMaxPermSize large and XXPermSize large)
Created attachment 244209 [details] screenshot 2 (XXMaxPermSize large and XXPermSize small)
Created attachment 244210 [details] screenshot 3 (XXMaxPermSize large and XXPermSize not set)
(In reply to Steven Spungin from comment #16) Thanks for posting these insights. They can be helpful for others that are hit by this problem in Luna. However, I don't think PDE should try to do anything about this for Mars. At the time Mars will ship, Java SE 7 will be EOL. If you still see such problem with Java SE 8, please file a bug for Oracle.
(In reply to Markus Keller from comment #20) > (In reply to Steven Spungin from comment #16) > Thanks for posting these insights. They can be helpful for others that are > hit by this problem in Luna. > > However, I don't think PDE should try to do anything about this for Mars. At > the time Mars will ship, Java SE 7 will be EOL. If you still see such > problem with Java SE 8, please file a bug for Oracle. Seeing that Java 8 has no perm gen space, I don't think this will be an issue. However, I am curious to know what the usage stats concerning Java version and Eclipse installs are. This PermGen issue has been a huge problem for users. Take a look at how many related bugs and issues there are! Instead of pointing a finger a Oracle, I would at the very least consider putting a minimal value for -XX:PermSize along with -XX:MaxPermSize in the ini. Java 8 will ignore the setting anyway. Eclipse is FAR from graceful when it comes to handling lack of PermGen space, and anything that can be done to prevent longer load times and system freezes would certainly be appreciated.
