Community
Participate
Working Groups
I've noticed OutOfMemoryErrors when I come in some mornings. I'm going to try some profiling, to see if I can narrow down what's doing this. PW
I think I'm right at the edge now...my mem usage is at 491 of 495 and my performance has dropped *significantly*... IMO we should fix this before M6 goes out since the optics (i.e. flame-fest) would be potentially quite damaging.
I agree there seems to be a problem here. I did a fresh install, opened an empty workbench, and let it sit except for starting the "heap display", and overnight saw the memory use increase by a factor of 2 or 3. (2, on linux, nearly 3 on windows). This morning I set max heap real low (60 g), and got an our of memory error after it just sat for 2 or 3 hours. I took a peek at the heap dump (using MAT) and unfortunately nothing obviously jumped out, to me. Something that's going to take some study. In other words, think we'll have to live with it for M6, unless someone is busy tracking this down?
We have been looking at it, but haven't been able to track it to something specific yet and will have to continue our analysis in M7 PW
Bogdan has tracked it down to the new workbench-auto-save feature, Bug 2369. It clones a model and then uses an EMF Resource to write it out. But that leaves the Resource (with the entire cloned model) in the ResourceSet. It needs to be unloaded and removed. PW
I've pushed a fix as https://git.eclipse.org/r/#/c/11311/ PW
The workaround for M6 is to set the Preferences>General>"Workbench save interval" to 0, which disables it. PW
Does resource.unload() really work? Why are we creating the resource through the ResourceSet instead of simply creating an instance ourselves?
The resourceSet.getResources().remove(*) works, and prevents the number of resources from growing in the resource set (which is the current leak). As for the why, it's because that method exists. Why, do you think it just creating a ResourceSetImpl() inline would work? Our own ResourceSetImpl is pre-configured with a lot of stuff: org.eclipse.e4.ui.internal.workbench.ResourceHandler.init() PW
I've released the fix as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=518a06e4208a966fa0644ba2a55163310dd22a09 for now. I've confirmed that with the fix, we don't accumulate model copies. We're going to run our OOME test overnight again with the fix to confirm. PW
Clearing the resources removed the major memory leak (150Meg over 48 hours). PW
(In reply to comment #6) > The workaround for M6 is to set the Preferences>General>"Workbench save > interval" to 0, which disables it. > > PW Tried that, but "Value must be an Integer between 1 and 9,999"
(In reply to comment #11) > (In reply to comment #6) > > The workaround for M6 is to set the Preferences>General>"Workbench save > > interval" to 0, which disables it. > > > > PW > > Tried that, I'd bet you did not ;-). You probably tried to change the similar value on the on the "Workbench" preference page.
(In reply to comment #11) > Tried that, but "Value must be an Integer between 1 and 9,999" Make sure you're on the General preference page (I think Workspace has something that looks similar, but it's about workspace not workbench) PW
Yes, both of you are right, I tried "Workspace save interval (in minutes):" where I should've used "Workbench save interval (in minutes):" I have a sense of an inkling that this will not be the last false alarm in this matter ... And then: why does one accept 0 where the other does not?
(In reply to comment #14) > And then: why does one accept 0 where the other does not? We planned for this bug ;-)
Verified the fix from Comment 9. Left the profiler running for 36 hours - no more more memory growth.
*** Bug 404588 has been marked as a duplicate of this bug. ***
There are two issues related to this functionality: 1) If you set the interval to 0, you won't be able to change it without restarting the workspace because the autoSaveJob isn't created (if the preference is set when starting Eclipse) or isn't rescheduled (if it is set to 0 using the General preferences page). 2) If the interval != 0, Eclipse starts the autoSaveJob job that runs forever. There isn't any such a job in Eclipse and this breaks our tests. See https://github.com/jbosstools/jbosstools-base/blob/master/tests/plugins/org.jboss.tools.tests/src/org/jboss/tools/test/util/JobUtils.java and https://issues.jboss.org/browse/JBIDE-13973 I suppose this has to be run in a separate thread that is always created, sleeps for saveInterval ms (or some constant interval if saveInterval=0) and, after that, calls persist in a new job if saveInterval>0. Also, I suppose this preference would have to be 0 by default because that is behaviour users expect. This would also speed up tests that don't test this preference.
(In reply to comment #18) > There are two issues related to this functionality: > > 1) If you set the interval to 0, you won't be able to change it without > restarting the workspace because the autoSaveJob isn't created (if the > preference is set when starting Eclipse) or isn't rescheduled (if it is set > to 0 using the General preferences page). > > 2) If the interval != 0, Eclipse starts the autoSaveJob job that runs > forever. There isn't any such a job in Eclipse and this breaks our tests. > See > https://github.com/jbosstools/jbosstools-base/blob/master/tests/plugins/org. > jboss.tools.tests/src/org/jboss/tools/test/util/JobUtils.java and > https://issues.jboss.org/browse/JBIDE-13973 > > I suppose this has to be run in a separate thread that is always created, > sleeps for saveInterval ms (or some constant interval if saveInterval=0) > and, after that, calls persist in a new job if saveInterval>0. > > Also, I suppose this preference would have to be 0 by default because that > is behaviour users expect. This would also speed up tests that don't test > this preference. Please file a separate bug report.
I have created #405356
*** Bug 407139 has been marked as a duplicate of this bug. ***
in 4.3.0.I20130516-2200 PW
