Hi,
Now that Eclipse requires IcedTea by deault on x86 and x86_64 I'd like to change the default vm memory settings to be something a little more sane. Right now the -vmargs option is set to "-Xms40m -Xmx256m". What should I change it to?
Thanks, Ben
* Ben Konrath bkonrath@redhat.com [2007-08-31 15:49]:
Now that Eclipse requires IcedTea by deault on x86 and x86_64 I'd like to change the default vm memory settings to be something a little more sane. Right now the -vmargs option is set to "-Xms40m -Xmx256m". What should I change it to?
I think a higher minimum is in order. There's actually a bug open at eclipse.org (I don't have the number handy) about this. IIRC, the platform team didn't want to change the default since they're not shipping an IDE :) There were sensible values in the bug, though.
FWIW, when I use IcedTea I use:
-Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m
But I have 2 GB of memory.
Andrew
On Fri, 2007-08-31 at 17:04 -0400, Andrew Overholt wrote:
FWIW, when I use IcedTea I use:
-Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m
I would suggest a lower -Xms and no -XX:PermSize (causing the starting size to be the default, 64MB for the 32-bit VM). The initial sizes don't need to be too large since some people may have less memory and/or small workspaces. It's just important to set a reasonable maximum to avoid OOMs (of the heap or permanent generation). Also, it's worth considering that the 64-bit version needs more memory.
Regards, Ismael
* Ismael Juma mlists@juma.me.uk [2007-08-31 17:21]:
On Fri, 2007-08-31 at 17:04 -0400, Andrew Overholt wrote:
FWIW, when I use IcedTea I use:
-Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m
I would suggest a lower -Xms and no -XX:PermSize (causing the starting size to be the default, 64MB for the 32-bit VM). The initial sizes don't need to be too large since some people may have less memory and/or small workspaces. It's just important to set a reasonable maximum to avoid OOMs (of the heap or permanent generation). Also, it's worth considering that the 64-bit version needs more memory.
Thanks for the suggestions, Ishmael.
I just ran into java.lang.OutOfMemoryError: PermGen space when synchronizing a project in Eclipse.
Does the IcedTea team have any suggestions here?
Thanks,
Andrew
Could be nice if the eclipse startup script contained some code to detect the memory size, and according to that set the permsize to mem/10 and Xms and Xmx to mem/2 or something close to that.
Just my 2 cents...
/Soren
On Mon, 10 Sep 2007 13:50:50 -0400 Andrew Overholt overholt@redhat.com wrote:
- Ismael Juma mlists@juma.me.uk [2007-08-31 17:21]:
On Fri, 2007-08-31 at 17:04 -0400, Andrew Overholt wrote:
FWIW, when I use IcedTea I use:
-Xms512m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m
I would suggest a lower -Xms and no -XX:PermSize (causing the starting size to be the default, 64MB for the 32-bit VM). The initial sizes don't need to be too large since some people may have less memory and/or small workspaces. It's just important to set a reasonable maximum to avoid OOMs (of the heap or permanent generation). Also, it's worth considering that the 64-bit version needs more memory.
Thanks for the suggestions, Ishmael.
I just ran into java.lang.OutOfMemoryError: PermGen space when synchronizing a project in Eclipse.
Does the IcedTea team have any suggestions here?
Thanks,
Andrew
* Søren Mathiasen soren@schantz.com [2007-09-11 03:55]:
Could be nice if the eclipse startup script contained some code to detect the memory size, and according to that set the permsize to mem/10 and Xms and Xmx to mem/2 or something close to that.
Yeah, but we don't have and don't want to have a wrapper script. I guess we could add it into the binary launcher ...
Andrew
Andrew Overholt writes:
- Søren Mathiasen soren@schantz.com [2007-09-11 03:55]:
Could be nice if the eclipse startup script contained some code to detect the memory size, and according to that set the permsize to mem/10 and Xms and Xmx to mem/2 or something close to that.
Yeah, but we don't have and don't want to have a wrapper script. I guess we could add it into the binary launcher ...
I think we should just change the limits. For example, it's a fairly trivial matter to change the default MaxPermSize in hotspot/src/cpu/x86/vm/c2_globals_x86.hpp from the current
define_pd_global(uintx, MaxPermSize, ScaleForWordSize(64*M));
to something more suitable. Linux doesn't actually allocate memory until it's used, so I'm not convinced that the "keep the limit small for users with small memory" actually applies.
So, why don't I just patch IcedTea to use your values as defaults? You can then try the resulting IcedTea, make dure it works, and it'll be in the next IcedTea release. If anyone screams we can always change the default back down again, but I doubt very much it'll ever happen.
Andrew.
* Andrew Haley aph@redhat.com [2007-10-05 08:47]:
So, why don't I just patch IcedTea to use your values as defaults?
That would be awesome. I think Tom Fitzsimmons might actually have some better values, but anything higher would rock.
Thanks,
Andrew
Andrew Overholt writes:
- Andrew Haley aph@redhat.com [2007-10-05 08:47]:
So, why don't I just patch IcedTea to use your values as defaults?
That would be awesome. I think Tom Fitzsimmons might actually have some better values, but anything higher would rock.
Alright, so I need to do the experiment:
Duplicate the failures -- you must tell me exactly what to do.
Rebuild with new values.
Confirm that the failures no longer happen.
Andrew.
* Andrew Haley aph@redhat.com [2007-10-05 09:01]:
Andrew Overholt writes:
- Andrew Haley aph@redhat.com [2007-10-05 08:47]:
So, why don't I just patch IcedTea to use your values as defaults?
That would be awesome. I think Tom Fitzsimmons might actually have some better values, but anything higher would rock.
Alright, so I need to do the experiment:
Duplicate the failures -- you must tell me exactly what to do.
Rebuild with new values.
Confirm that the failures no longer happen.
It may be easier for me to do this. Josh Sumali can help as well as he can now reliably crash Eclipse within a few minutes. It's difficult to reproduce with a simple "run these steps" and even with a large workspace, I find it happens erratically.
When was the last time I told you something was wrong and it was easy to reproduce? :)
Andrew
Andrew Overholt writes:
- Andrew Haley aph@redhat.com [2007-10-05 09:01]:
Andrew Overholt writes:
- Andrew Haley aph@redhat.com [2007-10-05 08:47]:
So, why don't I just patch IcedTea to use your values as defaults?
That would be awesome. I think Tom Fitzsimmons might actually have some better values, but anything higher would rock.
Alright, so I need to do the experiment:
Duplicate the failures -- you must tell me exactly what to do.
Rebuild with new values.
Confirm that the failures no longer happen.
It may be easier for me to do this. Josh Sumali can help as well as he can now reliably crash Eclipse within a few minutes. It's difficult to reproduce with a simple "run these steps" and even with a large workspace, I find it happens erratically.
OK, I'll make two packages, one with and one without the patch. Which arch do you prefer?
When was the last time I told you something was wrong and it was easy to reproduce? :)
Uh, yeah.
Andrew.
* Andrew Haley aph@redhat.com [2007-10-05 09:20]:
Andrew Overholt writes:
- Andrew Haley aph@redhat.com [2007-10-05 09:01]:
Andrew Overholt writes:
- Andrew Haley aph@redhat.com [2007-10-05 08:47]:
So, why don't I just patch IcedTea to use your values as defaults?
That would be awesome. I think Tom Fitzsimmons might actually have some better values, but anything higher would rock.
Alright, so I need to do the experiment:
Duplicate the failures -- you must tell me exactly what to do.
Rebuild with new values.
Confirm that the failures no longer happen.
It may be easier for me to do this. Josh Sumali can help as well as he can now reliably crash Eclipse within a few minutes. It's difficult to reproduce with a simple "run these steps" and even with a large workspace, I find it happens erratically.
OK, I'll make two packages, one with and one without the patch. Which arch do you prefer?
i386.
Thanks,
Andrew
Andrew Overholt wrote:
- Andrew Haley aph@redhat.com [2007-10-05 09:01]:
Andrew Overholt writes:
- Andrew Haley aph@redhat.com [2007-10-05 08:47]:
So, why don't I just patch IcedTea to use your values as defaults?
That would be awesome. I think Tom Fitzsimmons might actually have some better values, but anything higher would rock.
Alright, so I need to do the experiment:
Duplicate the failures -- you must tell me exactly what to do.
Rebuild with new values.
Confirm that the failures no longer happen.
It may be easier for me to do this. Josh Sumali can help as well as he can now reliably crash Eclipse within a few minutes. It's difficult to reproduce with a simple "run these steps" and even with a large workspace, I find it happens erratically.
When was the last time I told you something was wrong and it was easy to reproduce? :)
Andrew
-- fedora-devel-java-list mailing list fedora-devel-java-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
There's no real set list of things to do, but what I find works best is doing many *different* things (as to load classes into perm gen space). This typically involves doing things like:
-cvs update, cvs diffing -Source > Format , Source > Clean Up -Right click on a project, enable maven, play around with the maven settings -Running programs differently (Right click > run as > java applet, or java application, OSGI, etc) -Debugging programs differently -Looking at eclipse help (Help Contents, Dynamic Help, etc)
Using more plugins would probably be easier in terms of crashing Eclipse, but I can do so with just Maven and Mylyn on Eclipse as plugins (and a 64mb permgen limit).
Josh
Joshua Sumali writes:
There's no real set list of things to do, but what I find works best is doing many *different* things (as to load classes into perm gen space). This typically involves doing things like:
-cvs update, cvs diffing -Source > Format , Source > Clean Up -Right click on a project, enable maven, play around with the maven settings -Running programs differently (Right click > run as > java applet, or java application, OSGI, etc) -Debugging programs differently -Looking at eclipse help (Help Contents, Dynamic Help, etc)
Using more plugins would probably be easier in terms of crashing Eclipse, but I can do so with just Maven and Mylyn on Eclipse as plugins (and a 64mb permgen limit).
OK, I'm gonna let you do it. :-)
I can supply two binaries for x86_64 quite easily. I can do it for 386 if I have to, but that's much harder for me. (32-bit is *so * twentieth century!)
Andrew.
Andrew Haley wrote:
Joshua Sumali writes:
There's no real set list of things to do, but what I find works best is doing many *different* things (as to load classes into perm gen space). This typically involves doing things like:
-cvs update, cvs diffing -Source > Format , Source > Clean Up -Right click on a project, enable maven, play around with the maven settings -Running programs differently (Right click > run as > java applet, or java application, OSGI, etc) -Debugging programs differently -Looking at eclipse help (Help Contents, Dynamic Help, etc)
Using more plugins would probably be easier in terms of crashing Eclipse, but I can do so with just Maven and Mylyn on Eclipse as plugins (and a 64mb permgen limit).
OK, I'm gonna let you do it. :-)
I can supply two binaries for x86_64 quite easily. I can do it for 386 if I have to, but that's much harder for me. (32-bit is *so * twentieth century!)
Andrew.
At the moment I only have access to a 32 bit machine for testing, but x86_64 could be tested next Tuesday at the earliest (Monday being a holiday).
Also, why 2 binaries?
Josh
Joshua Sumali writes:
Andrew Haley wrote:
Joshua Sumali writes:
There's no real set list of things to do, but what I find works best is doing many *different* things (as to load classes into perm gen space). This typically involves doing things like:
-cvs update, cvs diffing -Source > Format , Source > Clean Up -Right click on a project, enable maven, play around with the maven settings -Running programs differently (Right click > run as > java applet, or java application, OSGI, etc) -Debugging programs differently -Looking at eclipse help (Help Contents, Dynamic Help, etc)
Using more plugins would probably be easier in terms of crashing Eclipse, but I can do so with just Maven and Mylyn on Eclipse as plugins (and a 64mb permgen limit).
OK, I'm gonna let you do it. :-)
I can supply two binaries for x86_64 quite easily. I can do it for 386 if I have to, but that's much harder for me. (32-bit is *so * twentieth century!)
At the moment I only have access to a 32 bit machine for testing, but x86_64 could be tested next Tuesday at the earliest (Monday being a holiday).
Also, why 2 binaries?
Science. :-) I want to prove that it works with one, and not with the other. Since I can't prove that my pre-patch build is identical to the RPM, you have to test both.
Andrew.
Andrew Haley wrote:
Andrew Overholt writes:
- Søren Mathiasen soren@schantz.com [2007-09-11 03:55]:
Could be nice if the eclipse startup script contained some code to detect the memory size, and according to that set the permsize to mem/10 and Xms and Xmx to mem/2 or something close to that.
Yeah, but we don't have and don't want to have a wrapper script. I guess we could add it into the binary launcher ...
I think we should just change the limits. For example, it's a fairly trivial matter to change the default MaxPermSize in hotspot/src/cpu/x86/vm/c2_globals_x86.hpp from the current
define_pd_global(uintx, MaxPermSize, ScaleForWordSize(64*M));
to something more suitable. Linux doesn't actually allocate memory until it's used, so I'm not convinced that the "keep the limit small for users with small memory" actually applies.
So, why don't I just patch IcedTea to use your values as defaults?
I'd rather MaxPermSize be disabled entirely. Upping the limit just puts off the OOM JVM crash, when really the kernel should be left to handle memory pressure.
Tom
Thomas Fitzsimmons writes:
Andrew Haley wrote:
Andrew Overholt writes:
- Søren Mathiasen soren@schantz.com [2007-09-11 03:55]:
Could be nice if the eclipse startup script contained some code to detect the memory size, and according to that set the permsize to mem/10 and Xms and Xmx to mem/2 or something close to that.
Yeah, but we don't have and don't want to have a wrapper script. I guess we could add it into the binary launcher ...
I think we should just change the limits. For example, it's a fairly trivial matter to change the default MaxPermSize in hotspot/src/cpu/x86/vm/c2_globals_x86.hpp from the current
define_pd_global(uintx, MaxPermSize, ScaleForWordSize(64*M));
to something more suitable. Linux doesn't actually allocate memory until it's used, so I'm not convinced that the "keep the limit small for users with small memory" actually applies.
So, why don't I just patch IcedTea to use your values as defaults?
I'd rather MaxPermSize be disabled entirely. Upping the limit just puts off the OOM JVM crash, when really the kernel should be left to handle memory pressure.
I can understand why you say so, but I don't think this is a good idea. Sun's Java has never been tested with an unlimited MaxPermSize, so this would putting us into Space Cadet Explorer territory for AFAICS no important reason.
Maybe one day we can do this, but for the time being let's just try changing the defaults. OK?
Andrew.
Andrew Haley wrote:
Thomas Fitzsimmons writes:
Andrew Haley wrote:
Andrew Overholt writes:
- Søren Mathiasen soren@schantz.com [2007-09-11 03:55]:
Could be nice if the eclipse startup script contained some code to detect the memory size, and according to that set the permsize to mem/10 and Xms and Xmx to mem/2 or something close to that.
Yeah, but we don't have and don't want to have a wrapper script. I guess we could add it into the binary launcher ...
I think we should just change the limits. For example, it's a fairly trivial matter to change the default MaxPermSize in hotspot/src/cpu/x86/vm/c2_globals_x86.hpp from the current
define_pd_global(uintx, MaxPermSize, ScaleForWordSize(64*M));
to something more suitable. Linux doesn't actually allocate memory until it's used, so I'm not convinced that the "keep the limit small for users with small memory" actually applies.
So, why don't I just patch IcedTea to use your values as defaults?
I'd rather MaxPermSize be disabled entirely. Upping the limit just puts off the OOM JVM crash, when really the kernel should be left to handle memory pressure.
I can understand why you say so, but I don't think this is a good idea. Sun's Java has never been tested with an unlimited MaxPermSize, so this would putting us into Space Cadet Explorer territory for AFAICS no important reason.
Have you checked if there's a way to make MaxPermSize unlimited using command-line options or other configuration hooks (i.e., in ways that Sun probably would have tested)? If removing the limit requires intrusive patching then I'm fine with just setting it "high".
Tom
Thomas Fitzsimmons writes:
Andrew Haley wrote:
Thomas Fitzsimmons writes:
Andrew Haley wrote:
Andrew Overholt writes:
I'd rather MaxPermSize be disabled entirely. Upping the limit just puts off the OOM JVM crash, when really the kernel should be left to handle memory pressure.
I can understand why you say so, but I don't think this is a good idea. Sun's Java has never been tested with an unlimited MaxPermSize, so this would putting us into Space Cadet Explorer territory for AFAICS no important reason.
Have you checked if there's a way to make MaxPermSize unlimited using command-line options or other configuration hooks (i.e., in ways that Sun probably would have tested)? If removing the limit requires intrusive patching then I'm fine with just setting it "high".
It's really simple: it just limits PermGen expansion to the preset limit:
// ...and no larger or smaller than our max and min allowed. desired_size = MAX2(MIN2(desired_size, _max_gen_size), _min_gen_size); assert(desired_size <= _max_gen_size, "just checking");
There's no special case for "unlimited" or anthing like that. In any case, we wouldn't want to prevent users from setting a limit if they wanted one: that would be removing useful functionality.
Andrew.
java-devel@lists.fedoraproject.org