A DESCRIPTION OF THE REQUEST :
I'm opening this request after thinking about bug 6969236 and implications for Eclipse. See

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969236

It appears the basic problem for Eclipse (and others) is the default "maximum" is not large enough, and that leads Eclipse (if not others) to have to set this non-standard value when Sun/Oracle VMs used.

This may be a naive request, but ... I've seen many complaints over the years about this default not being high enough. Besides the Eclipse history, I think this blog post has some interesting links in it
http://www.xlml.com/aehso/2007/04/05/the-dreaded-javalangoutofmemoryerror-permgen-space-exception/

I've not found any documents or news about any downside of setting this "too high" (e.g. setting the max to 256M) and from what I've seen/read, it's not really used, unless needed.

I think I recall, from years ago, that on "low memory" machines, e.g. 1 gig, that MaxPermSize and mx settings did interact on startup (that the vm would exit, if not enough physical memory to satisfy both. So, I understand there'd be some risk about changing this default, if existing users had their mx memory setting to "just barely fit" their existing memory.

That is why I say "smarter". Perhaps MaxPermSize default could be increased as a function of mx, if it was not otherwise specified. For example, if mx was set to 512M, MaxPermSize default set to 128M, if mx set to 768 or larger, then  MaxPermSize set to 256M. You might want more "steps" in between 64 M and 256M, but would not expect you'd have to go higher.

I realize the change would not be without risk. I guess it would subtly change the behavior (frequency?) of garbage collection. But, I thought it deserved a request, give the alternatives, and was surprised I couldn't find a request in this bugzilla system.

Thanks for considering.




JUSTIFICATION :
  Justification is mostly above ... seems easier for vast majority of end users to handle "maximum" case more invisibly.