MyEclipse :: View topic - Available Memory is Low (again) ?

MyEclipse: Available Memory is Low (again) ?

edbras - Apr 02, 2011 - 09:26 PM
Post subject: Available Memory is Low (again) ?

I recently installed MyEclipse 9 on my Windows box, with Dual Core and 4MB RAM with Windows 7 64 bit.

After using it for some time I keep getting this "Low Memory alert" again that surprised me. I had it sometimes on version 8.6, but accepted that it was probably because I was running it on the non-supported Windows 7 64 bit.

Now, I like to solve this once and for all. I tried many different memory settings in the myeclipse.ini file, but all doesn't seem to solve the problem.
Please some advice on this issue.

When the Low Memory popup appears, it shows the default (well know) text:
---
MyEclipse has detected less than 5% of the 50MB of PS Survivor Space (Heap memory) space remans.
It is strongly recommended that you exit and restart MyEclipse with the new virtual machine memory parameters to increase this memory. Failure to do so can result in data loss.
Recommended memory arguments:
-vmargs
-Xmx512m
-XX:MaxPermSize=256m
-XX:ReservedCodeCacheSize=64m
----

It doesn't explain where to set these settings, but I suppose that I have to set these in the myeclipse.ini, or not ??
The above recommended settings are a bit strange as my current settings are:
---
-vmargs
-Xms512m
-Xmx1024m
-XX:PermSize=512m
-XX:MaxPermSize=512m
-XX:ReservedCodeCacheSize=128m
---
Why does MyEclipse advice me to use settings that indicate the use of less memory?
You would expect that it will results in more problems.
But even if I change it to the recommended settings, the dialog keep appearing, even do I have still about 1GB of RAM available according to the task manager.
I am confused.
Some more details: I use MyEclipse 9.0 Pro version with many MyEcplise disabled. I have only Maven, Tomcat, Spring, Hibernate, and some more stuff enabled.
Extra plugin's installed: AJDT, Checkstyle, JIbx, testNG and subversive.
I have about 20 java projects open, with only a few using the above extra plugin's.

- Ed

Support-Brian - Apr 05, 2011 - 08:07 AM
Post subject:

Ed,

1) We have an issue with the memory monitor - while it does detect low memory correctly, the "suggested" settings are static and based on what values we do have in the ini file, we need to fix this and I have filed a bug to this effect.

2) Your new settings look fine - 64bit environments typically use more memory and we are working on changing the default values.

3) Are you running the 64bit installation of MyEclipse (you can install both 32 and 64 bit on 64 bit OS) - how did you install it?
After changing the memory settings, does it take longer for the warning to appear?
Are you starting the workspace with the MyEclipse configuration center open?

4) Are there any particular actions that you take which lead to this error repeatedly? Do you use our visual designers or is the workspace building when it appears? What parts of our Spring and Hibernate feature sets do you use - do you use the reverse engineering often, of instance?

Problems like this are hard to track down, the problem could be in MyEclipse or in your external plugins too. I have a few suggestions:
1) Go to Window > Preferences > MyEclipse > Validation > Spring
Ensure "use change detection" and "use non locking classloaders" are turned off.
Go to the Project Builders tab and disable the AOP reference model builder and the Spring Bean Meta Data Builder.

These are the only MyEclipse settings that I know of which could consume more memory if enabled, though should not be to this extent.

Restart MyEclipse and use it for awhile, does the memory situation improve?

2) Disable all your external plugins - I'm do not know how they work internally, but AJDT and Checkstyle could actually cause issues with memory as well. Again, use MyEclipse for awhile and observe the memory situation.

If either of these solutions work for you, we will know what plugins are causing the issues and can investigate further.

edbras - Apr 05, 2011 - 09:12 AM
Post subject:

Thanks for your answer.
Below you find my answers in response to your questions.
I have to say: the last few day's I haven't seen this memory alert anymore. No idea why.

Quote:

3) Are you running the 64bit installation of MyEclipse (you can install both 32 and 64 bit on 64 bit OS) - how did you install it?
After changing the memory settings, does it take longer for the warning to appear?
Are you starting the workspace with the MyEclipse configuration center open?

I have it installed by downloading the full-package from your website, and installed it as a 64 bit app. I couldn't install it through the customized installer as it didn't come through my proxy for some reason.
Yes it toke longer before the alert box appeared after changing the settings.
No, I start the MyEclipse editor perspective, hardly do anything with the configuration center.

Quote:

4) Are there any particular actions that you take which lead to this error repeatedly? Do you use our visual designers or is the workspace building when it appears? What parts of our Spring and Hibernate feature sets do you use - do you use the reverse engineering often, of instance?

Hard to say. I think it's when I am running tomcat 7 and gwt dev mode.
I don't use any visual designers. I don't use any reversed engineering tools.
I use as less plugin's as possible as they only can give me problems and it results in more time for a new developers to start.
I don't have projects marked as Hibernate/Spring (didn't add the Hibernate/Spring capabilities). I only use the view capabilities, that's it. I don't even have the gwt plugin installed, I don't need it, I have learned to do well without it. I only sometimes install it when making a AppEngine app.
I mostly use Myeclipse for the hot deployment for my web app on the Tomcat instance. The web app is the only project that is marked with Myeclipse capabilities (web capabilities in this case)
I have the following MyEclipse functionality enabled (but don't use them all): Desktop util, Hibernate, Jetty, Maven, Database, Spring, Tomcat, Web services.

Quote:

Problems like this are hard to track down, the problem could be in MyEclipse or in your external plugins too. I have a few suggestions:
1) Go to Window > Preferences > MyEclipse > Validation > Spring
Ensure "use change detection" and "use non locking classloaders" are turned off.

They were already turned off.

Quote:

Go to the Project Builders tab and disable the AOP reference model builder and the Spring Bean Meta Data Builder.

What is the effect of this?

Quote:

2) Disable all your external plugins - I'm do not know how they work internally, but AJDT and Checkstyle could actually cause issues with memory as well. Again, use MyEclipse for awhile and observe the memory situation.

Strange question. Basically you are asking me the impossible. Sorry, can't do this, as I need them and if I would, I could as well develop with VI.
As you can read I only have a minimum of plugin's installed/enabled, and those are required for normal/correct development.

Any more idea's?
Maybe better memory settings?
From your reading I notice that at least my memory settings are put in the correct place.
What about starting with the latest jre version instead of the embedded jre ?
- Ed

edbras - Apr 05, 2011 - 10:42 AM
Post subject:

Just got another Alert.
Strange as I was working on a tinny project with no tomcat running. Only GWT dev mode running...
However, I have about 20 projects open, but only about 5 files open.

Maybe it's useful.

Support-Brian - Apr 05, 2011 - 10:58 AM
Post subject:

Ed,

Memory issues are hard to track and there are a number of additional plugins in your configuration. My aim in asking you to disable plugins is not for you to do so permanently, but to help determine where the problem is. After you find that disabling either external plugins or some MyEclipse feature actually fixes your problem, then I know where to look for a leak, or, if the problem is in an external plugin - you will need to contact those developers to assist. Obviously, the ultimate goal is to have you running without issues with your existing configuration, but I can't help too much without knowing where to look.

From your latest comment it would appear that the GWT Dev mode is a common factor in your OOM experiences?

The AOP reference model builder: "Enables the use of the Beans Cross References View and the Spring IDE contributions to AJDT's Cross Reference View and Visualiser." If you don't use aspects in your Spring programs, or you don't have use for any of these views, you can turn this off. At this particular moment I cannot recall exactly the function of the other builder, beyond what is displayed in the description.

You could try using a more recent JRE, of course - though I doubt the problem would be in that area. I assume you know how to do this, let me know if you need help here.

edbras - Apr 08, 2011 - 04:52 PM
Post subject:

Thanks.
My answers:
I understand you but disabling for example the Jibx or AJDT plugin would result in a poor development situation as I can't run any of my tests.

Yes I do use Spring aspects and they are shown in the View through a little icon. I think this is what the builder does. Is this builder only for Visualization as far as you know? If so, I could turn it off,
I use jre 6.23

pmatignon - May 10, 2012 - 10:32 PM
Post subject: Why PS Survivor space ?

We are getting the PS Survivor space message one in a awhile as well. It used to be more frequent, but since moving to a 64-bit JVM (on Win 7, Oracle 1.6 JVM) with lot of headroom it is noticeably less frequent.

Still it happens, and never seems justified, in the sense that the heap is far from maxed out. Furthermore, it is our understanding that the default GC algorithm (ParallelGC, dynamic heap parameters) on this platform, is not going to suffer from survivor space filling up. Anything from Eden that doesn't fit in Survivor space goes straight to OldGen AFAIK.

Would it be a case of reporting a condition that's not a problem ? In other word, if our understanding of the survivor space is correct, the fact that it reaches 95+% utilization is terribly irrelevant, and does not purport a condition threatening the stability of the JVM (unlike, for instance, maxing out the PermGen, or the OldGen areas).

Unless, of course, your Engineers know that this particular condition is in fact significant, such as a pre-condition to a serious issue for instance.
But then, please help us understand what JVM memory settings need to be set here. If it's truly a problem with Survivor space, it's not just increasing overall head sapce, or even the YoungGen area as a whole. At the very least, this could include (Oracle JVM) : -XX:NewRatio, -XX:SurvivorRatio, -XX:TargetSurvivorRatio, ...
Or maybe you could recommend a JVM from a different vendor.

Thanks in advance.

Support-Brian - May 21, 2012 - 11:09 PM
Post subject:

Patrice,

Sorry for the delayed response - we are in the midst of our 10.5 release and it took me some time to look at our memory monitoring code.

Basically, our code reports a problem if the utilization of any of the pools is 95% or higher. You are correct that if you get the warning about the survivor space then the condition is likely not critical and overflow would go into the old gen area as you stated. This code was primarily put in place for cases where users would run MyEclipse with the default (or low) overall heap size which would certainly make MyEclipse sluggish, unresponsive or even cause it to crash.

I have a couple of questions:
1) When you see the low memory dialog, is it mostly about the survivor space? Have you noticed it complain about any other pool?
2) What memory settings *are* you using?
3) When warned, do you ignore the warning or restart MyEclipse? If ignored, does performance appear to be adversely affected?

I would not recommend another JVM or actually specifying any of the ratios. We'll re-run our stress tests with a focus on memory utilization and performance/recovery of MyEclipse when the utilization is high. Thank you for asking.

pmatignon - May 22, 2012 - 12:46 AM
Post subject:

Thank you Brian,

Regarding your 3 questions, see below:

1) We have seen it for other memory area (PermGen in particular), but we were able to make those mostly go away by sizing accordingly. So we're seeing this Survivor Space one most often now, but are unable to figure/find a setting that would address it (which makes sense if our interpretation is correct, which your investigation seems to support).

2) We're using (64-bit JVM, Win 7, JDK 6 u31):
-XX:MaxPermSize=768m
-XX:ReservedCodeCacheSize=128m
-Xmx3076m

3) I don't have good statistics about what our team members do when the dialog pops up, and whether those who choose to ignore it run into issues.
I usually choose to ignore it for a while, and did not notice any specific issues. However, I switch workspaces often enough that it might hide the problem. Overall, people tend to react quite sheepishly when encountering a memory exhaustion problem, and compounding the issue, is that the warning message urges you to change your memory settings. which makes this infrequent message terribly confusing and user education difficult.

Thanks again for looking into this.