Community
Participate
Working Groups
I downloaded the 64 bit Luna for OS X. Installed PDT dev tools. Doing simple editing, almost immediately ran into hangs with all CPUS (8) maxed, apparently doing never-ending gc. Looked into it and found the default launcher Xmx was only 512MB. That doesn't seem like an appropriate default for Eclipse, expecially on 64 bit platforms. 1.5-2GB has proven to be a more practical heap limit in my experience. Strongly recommend increasing this to prevent new user confusion.
With Java 8 the heap size is not needed / used anymore. As Eclipse Mars is planned to be released after the end of life of Java 7 I suggest to mark this bug as invalid.
(In reply to Lars Vogel from comment #1) > With Java 8 the heap size is not needed / used anymore. How have I not heard about this before! You not thinking of "maxpergen size" are you? (In reply to Toby Thain from comment #0) > Installed PDT dev tools. Doing simple editing, almost immediately ran into > hangs with all CPUS (8) maxed, apparently doing never-ending gc. > > Looked into it and found the default launcher Xmx was only 512MB. I believe PDT has much higher requirements than the SDK alone does, due to the way it does "indexing" with DTLK (I believe) ... so if that's the only known use-case with a problem, I suggest that PDT be the one to increase (and decrease) the max heap during the "configure" (and "unconfigure") stages of p2.
(In reply to David Williams from comment #2) > (In reply to Lars Vogel from comment #1) > > > With Java 8 the heap size is not needed / used anymore. > > How have I not heard about this before! You not thinking of "maxpergen size" > are you? Thanks for the correction. > (In reply to Toby Thain from comment #0) > > > Installed PDT dev tools. Doing simple editing, almost immediately ran into > > hangs with all CPUS (8) maxed, apparently doing never-ending gc. > > > > Looked into it and found the default launcher Xmx was only 512MB. > > I believe PDT has much higher requirements than the SDK alone does, due to > the way it does "indexing" with DTLK (I believe) ... so if that's the only > known use-case with a problem, I suggest that PDT be the one to increase > (and decrease) the max heap during the "configure" (and "unconfigure") > stages of p2. Great suggestion, moving to PDT.
Thanks for reopening. I am running JDK 7, as would anyone with a standard OS X install. As for appropriate heap size, the problem is certainly _not_ limited to PDT! I have long used Eclipse for Java dev (without even PDT installed) and based on that, anything under 1.5GB is likely to cause problems. Many co-workers had the same experience with the same conclusion. Does anyone have a real justification for a max of 512MB?
Adding Dani and Markus as two people who might have some insight's opinion on this issue (for the Platform, even those is currently in "PDT" after being moved). I certainly have no personal issue making it "huge" but I think the reason we've always made it as "small as possible" while still "working for most people" is that if we make it 1G or 1.5G, then those with only 4G on their machine may simply find that it does not start ... assuming OS takes a close to a couple G, and a few other apps running takes to another G ... but ... I may be working with "old information" and maybe things have changed now?
While I am very sympathetic to users on small machines, I believe this could be addressed by clearly announcing the increase in default Mx - in line with typical machines in use today - and at the same time making it clearer how to adjust the setting if someone is using a machine < 4GB. As a data point, the large Java shop I worked at (where everyone found < 1.5GB Eclipse heap was impractical) currently standardises on 16GB RAM in all developer desktops. I do think there is something anachronistic in the existing size (how LONG has it been 512MB? was it *ever* smaller than that??) especially for people specifically downloading a 64 bit build. Though the user experience will likely still be poor for those on 32 bit. Thanks for considering this issue!
(In reply to Toby Thain from comment #0) > I downloaded the 64 bit Luna for OS X. > > Installed PDT dev tools. Doing simple editing, almost immediately ran into > hangs with all CPUS (8) maxed, apparently doing never-ending gc. > > Looked into it and found the default launcher Xmx was only 512MB. > > That doesn't seem like an appropriate default for Eclipse, expecially on 64 > bit platforms. 1.5-2GB has proven to be a more practical heap limit in my > experience. > > Strongly recommend increasing this to prevent new user confusion. We are working on memory issues (sometimes together with DLTK team). Main issue is a DLTK H2Index which will be reduced in new version. Since PDT 3.4 + DLTK 5.1.1 -Xmx512m should be enough even on larger workspaces.
(In reply to Dawid Pakula from comment #7) > (In reply to Toby Thain from comment #0) > > I downloaded the 64 bit Luna for OS X. > > > > Installed PDT dev tools. Doing simple editing, almost immediately ran into > > hangs with all CPUS (8) maxed, apparently doing never-ending gc. > > ... > > We are working on memory issues (sometimes together with DLTK team). Main > issue is a DLTK H2Index which will be reduced in new version. > > Since PDT 3.4 + DLTK 5.1.1 -Xmx512m should be enough even on larger > workspaces. My system has PDT 3.3.1 + DLTK 5.0.0, for the record.
(In reply to Toby Thain from comment #6) > While I am very sympathetic to users on small machines, I believe this could > be addressed by clearly announcing the increase in default Mx - in line with > typical machines in use today - and at the same time making it clearer how > to adjust the setting if someone is using a machine < 4GB. I think one problem with this idea is that people with machines with 4GB, are probably less able/likely to know about "setting mx values" (you know, since probably "casual uses"). Plus, don't forget, some people end up with a number of instances of Eclipse running ... some perhaps as "rcp apps", some as having several IDEs running at once. > As a data point, the large Java shop I worked at (where everyone found < > 1.5GB Eclipse heap was impractical) currently standardises on 16GB RAM in > all developer desktops. Tody, There are some other approaches you could take, for "your shop". 1) If you typically download an "EPP package", you might open a bug under EPP (under Technology top level component). I know they sometimes have their own "mx values" ... such as, I believe for JEE Package they set it at 786m? 2) There are ways you can define a special IU, just for setting eclipse.ini values. See Paul Webster's blog post at http://pweclipse.blogspot.com/2012_02_01_archive.html This would allow "your shop" to have a small "local repo" that all your developers could use to have a consistent value. I know not as easy as an "out of box" solution, but it is a good solution if your shop has needs that are not typical (average) -- and I suspect, the Platform wants to set these values as "minimal", not "average", just to avoid people running out of memory immediately, especially if running many instances of Eclipse. [Though, admit, I *think* most VMs do better these days at "returning" memory to the OS, if they are not really using all of mx (that is, they do not "reserve" all that memory and hang on to it, like they used to) ... but, I do not know enough about it, to say for sure. 3) There is a project call Oomph, that will help "standardize" a set of preferences that can be shared among many instances of Eclipse installs. I am not actually positive it covers "mx" values, but you might check it out, and if nothing else, it might help "your shop" all get setup more easily and quickly and consistently over many preference values. I know there is work being done to make this part of (nearly) every EPP package, so I am sure they'd appreciate early feedback and feature requests. > I do think there is something anachronistic in the existing size (how LONG > has it been 512MB? was it *ever* smaller than that??) especially for people > specifically downloading a 64 bit build. Though the user experience will > likely still be poor for those on 32 bit. > I think the last time is was increased was in 2009, according to bug 265525.
Six years without an (In reply to David Williams from comment #9) > (In reply to Toby Thain from comment #6) > > While I am very sympathetic to users on small machines, I believe this could > > be addressed by clearly announcing the increase in default Mx - in line with > > typical machines in use today - and at the same time making it clearer how > > to adjust the setting if someone is using a machine < 4GB. > > I think one problem with this idea is that people with machines with 4GB, > are probably less able/likely to know about "setting mx values" (you know, > since probably "casual uses"). Plus, don't forget, some people end up with a > number of instances of Eclipse running ... some perhaps as "rcp apps", some > as having several IDEs running at once. > > > As a data point, the large Java shop I worked at (where everyone found < > > 1.5GB Eclipse heap was impractical) currently standardises on 16GB RAM in > > all developer desktops. > > Tody, > There are some other approaches you could take, for "your shop". > 1) If you typically download an "EPP package", you might open a bug under > EPP (under Technology top level component). I know they sometimes have their > own "mx values" ... such as, I believe for JEE Package they set it at 786m? > 2) There are ways you can define a special IU, just for setting eclipse.ini > values. See Paul Webster's blog post at > http://pweclipse.blogspot.com/2012_02_01_archive.html > This would allow "your shop" to have a small "local repo" that all your > developers could use to have a consistent value. I know not as easy as an > "out of box" solution, but it is a good solution if your shop has needs that > are not typical (average) -- and I suspect, the Platform wants to set these > values as > "minimal", not "average", just to avoid people running out of memory > immediately, especially if running many instances of Eclipse. [Though, > admit, > I *think* most VMs do better these days at "returning" memory to the OS, if > they are not really using all of mx (that is, they do not "reserve" all that > memory and hang on to it, like they used to) ... but, I do not know enough > about it, to say for sure. > 3) There is a project call Oomph, that will help "standardize" a set of > preferences that can be shared among many instances of Eclipse installs. I > am not actually positive it covers "mx" values, but you might check it out, > and if nothing else, it might help "your shop" all get setup more easily and > quickly and consistently over many preference values. I know there is work > being done to make this part of (nearly) every EPP package, so I am sure > they'd appreciate early feedback and feature requests. > > > I do think there is something anachronistic in the existing size (how LONG > > has it been 512MB? was it *ever* smaller than that??) especially for people > > specifically downloading a 64 bit build. Though the user experience will > > likely still be poor for those on 32 bit. > > > > I think the last time is was increased was in 2009, according to bug 265525. Six years without an increase does not seem to reflect the rate at which workstation configurations have changed, especially in commercial development environments (I mentioned the 64 bit + 16GB standard that was in place last year where I worked). The fact that it's arcane to change -Xmx hurts everyone, so I don't think it's an argument for leaving the configuration at a setting that's designed for the lowest percentile of users. User survey data should be able to guide this decision effectively? As for "our shop", the need to increase it was "tribal knowledge" that was obtained through fairly costly trial and error. The standard environment should certainly have included this change, but that doesn't help those who opt for a 3P download (perhaps to get a current version).
Note, I did open a new "Platform bug", bug 457489, to cover this topic at the platform level. I do think EPP packages need to make their own informed decisions ... I'm sure if we in Platform make any changes, it might still not be suitable for EPP packages. But, it was just thought Toby raises some good points, that deserve more research, investigation, and discussion.
Moving to php epp
See bug 459596 for the current status (Mars/4.5): The EPP packages are using now at least these settings: -Xms256m -Xmx1024m If this still doesn't satisfy the needs of the PHP package users, I would suggest to increase the values of this package.
PHP package no longer need so much ram. Also 2019-12 has upgraded values to Xmx=2048
