default vm memory settings for fedora eclipse

[Benjamin Konrath]

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

[Andrew Overholt]

* Ben Konrath <bkonrath(a)redhat.com&gt; [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

[Ismael Juma]

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

[Andrew Overholt]

* Ismael Juma <mlists(a)juma.me.uk&gt; [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]

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(a)redhat.com&gt; wrote:

>  * Ismael Juma <mlists(a)juma.me.uk&gt; [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

[Andrew Overholt]

* Søren Mathiasen <soren(a)schantz.com&gt; [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 Haley]

Andrew Overholt writes:
>  * Søren Mathiasen <soren(a)schantz.com&gt; [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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Andrew Overholt]

* Andrew Haley <aph(a)redhat.com&gt; [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 Haley]

Andrew Overholt writes:
>  * Andrew Haley <aph(a)redhat.com&gt; [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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Andrew Overholt]

* Andrew Haley <aph(a)redhat.com&gt; [2007-10-05 09:01]:
>  Andrew Overholt writes:
>   > * Andrew Haley <aph(a)redhat.com&gt; [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 Haley]

Andrew Overholt writes:
>  * Andrew Haley <aph(a)redhat.com&gt; [2007-10-05 09:01]:
>  > Andrew Overholt writes:
>  >  > * Andrew Haley <aph(a)redhat.com&gt; [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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Andrew Overholt]

* Andrew Haley <aph(a)redhat.com&gt; [2007-10-05 09:20]:
>  Andrew Overholt writes:
>   > * Andrew Haley <aph(a)redhat.com&gt; [2007-10-05 09:01]:
>   > > Andrew Overholt writes:
>   > >  > * Andrew Haley <aph(a)redhat.com&gt; [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

[Joshua Sumali]

Andrew Overholt wrote:
>  * Andrew Haley <aph(a)redhat.com&gt; [2007-10-05 09:01]:
>    
> > Andrew Overholt writes:
> >  > * Andrew Haley <aph(a)redhat.com&gt; [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(a)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

[Andrew Haley]

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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Joshua Sumali]

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

[Andrew Haley]

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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Thomas Fitzsimmons]

Andrew Haley wrote:
>  Andrew Overholt writes:
>   > * Søren Mathiasen <soren(a)schantz.com&gt; [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

[Andrew Haley]

Thomas Fitzsimmons writes:
>  Andrew Haley wrote:
>  > Andrew Overholt writes:
>  >  > * Søren Mathiasen <soren(a)schantz.com&gt; [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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903

[Thomas Fitzsimmons]

Andrew Haley wrote:
>  Thomas Fitzsimmons writes:
>   > Andrew Haley wrote:
>   > > Andrew Overholt writes:
>   > >  > * Søren Mathiasen <soren(a)schantz.com&gt; [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

[Andrew Haley]

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.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903