Community
Participate
Working Groups
I updated my 3.6 RC1 environment to 3.6 RC2 today without any problem. I decided to update my Babel French translation for Eclipse using the update site http://build.eclipse.org/technology/babel/update-site/R0.8.0/helios/ Computing the requirements (right after choosing the element to update and clicking next) makes eclipse run at 27% on my quad core for a while, and ends up with a OOM exception. java.lang.OutOfMemoryError: Java heap space at org.eclipse.ui.internal.progress.ProgressManager$3.updateFor(ProgressManager.java:514) at org.eclipse.ui.internal.progress.ProgressManager$3.scheduled(ProgressManager.java:477) at org.eclipse.core.internal.jobs.JobListeners$5.notify(JobListeners.java:49) at org.eclipse.core.internal.jobs.JobListeners.doNotify(JobListeners.java:96) at org.eclipse.core.internal.jobs.JobListeners.scheduled(JobListeners.java:162) at org.eclipse.core.internal.jobs.JobManager.schedule(JobManager.java:1122) at org.eclipse.core.internal.jobs.InternalJob.schedule(InternalJob.java:427) at org.eclipse.core.runtime.jobs.Job.schedule(Job.java:436) at org.eclipse.ui.internal.ide.application.IDEIdleHelper$1.run(IDEIdleHelper.java:156) at org.eclipse.swt.widgets.Display.timerProc(Display.java:4104) at org.eclipse.swt.internal.gtk.OS._g_main_context_iteration(Native Method) at org.eclipse.swt.internal.gtk.OS.g_main_context_iteration(OS.java:2224) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3157) at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:173) at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:388) at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1008) at org.eclipse.equinox.internal.p2.ui.dialogs.ProvisioningOperationWizard.recomputePlan(ProvisioningOperationWizard.java:205) at org.eclipse.equinox.internal.p2.ui.dialogs.ProvisioningOperationWizard.getNextPage(ProvisioningOperationWizard.java:104) at org.eclipse.equinox.internal.p2.ui.dialogs.WizardWithLicenses.getNextPage(WizardWithLicenses.java:58) at org.eclipse.jface.wizard.WizardPage.getNextPage(WizardPage.java:172) at org.eclipse.jface.wizard.WizardDialog.nextPressed(WizardDialog.java:887) at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:426) at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1234) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3540) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3159) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.equinox.p2.ui.ProvisioningUI.openInstallWizard(ProvisioningUI.java:206) at org.eclipse.equinox.internal.p2.ui.sdk.InstallNewSoftwareHandler.doExecute(InstallNewSoftwareHandler.java:31)
I updated in eclipse.ini -Xmx384m by -Xmx2048m and it works fine (I got 4GB). It is sort of a pain that the end user has to adjust the memory settings there. Note that AFAIK, Sun VMs on 64 bits arch do behave like IBM VMs: they just adapt their memory settings to the consumption of the app. So I suggest in the future to remove -Xms and -Xmx VM parameters in eclipse.ini on 64 bits arch platforms.
Normally, I think 512Mo is enough. This is also the default memory setting for the packages.
The default value in my eclipse.ini is 384m. That value could be updated to 512m for 3.6 final. I guess that most developers have now a computer with at least 1GB of RAM.
*** Bug 318705 has been marked as a duplicate of this bug. ***
*** Bug 319062 has been marked as a duplicate of this bug. ***
I am generalizing the title based on the duplicates. It is clear our memory performance when dealing with large repositories needs improvement.
See also bug 251630 and bug 272771.
I think we can mark this fixed given all of Dean's work on memory improvements in 3.7. Combined, these fixes add up to significant memory reduction: https://bugs.eclipse.org/bugs/show_bug.cgi?id=329386 https://bugs.eclipse.org/bugs/show_bug.cgi?id=329385 https://bugs.eclipse.org/bugs/show_bug.cgi?id=324873 https://bugs.eclipse.org/bugs/show_bug.cgi?id=329384 Some stats (see bug 329384 for details): In total the combined strategies lead to the following savings: Helios: 20.9 Meg (57%) reduction for a retained size of 15.6 Meg I-Build: 24 Meg (84%) reduction for a retained size of 4.6 Meg As well as retained used heap savings the strategies conserved allocated heap space which has other benefits such as decreased GC time. Helios: 164 Meg max heap allocated down to 122 Meg. I-Build 86 Meg max heap allocated down to 40 Meg.
