Andrew Haley wrote:
Thomas Fitzsimmons writes:
> Andrew Haley wrote:
> > Andrew Overholt writes:
> > > * Søren Mathiasen <soren(a)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.
> > > 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
> > 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".