Increase memory limits for IcedTea

[Peter B. Kessler]

You could do something ergonomic like looking to see how much
memory the machine has, and guessing what kinds of applications
will be run on it that way.  But basically you are guessing
what the application needs before it starts running, which isn't
a good way to go.  I sometimes wish we had the luxury of knowing
what kinds of applications a particular installation will run,
rather than having to balance the needs of applets in browsers
and servers running applications with 32GB heaps.

Note that the maximum space sizes only reserve memory, they
don't commit it, so you are just tying up address space and
swap space, not memory, if you don't actually grow into that
space.

The right solution is to make it so the heap doesn't have to
be in contiguous memory.  Anyone want to help work on that?

			... peter

Andrew Haley wrote:

> The fairly low default limits on PermGen and MaxHeap space cause a
> great deal of trouble on Linux, partiularly when running Eclipse.
> Fedora maintainers considered adding a special wrapper script to
> Eclipse that sets "-XX:MaxPermSize=128m" or something similar, but
> this would only solve the problem for Eclipse: non-Eclipse
> applications would continue to be bitten the same way.
> 
> In the end, Sun's Java seems to be the only VM that is affected by the
> VMGen limit, and there are many references on the web to confused
> users hitting it and having no idea how to proceed.  It makes sense
> for Fedora and other Linux distros to bump the limit to something that
> better fits the kinds of applications people are running.
> 
> There was some talk about removing these limits entirely, but:
> 
> 1.  It is sometimes useful to set a low limit for some processes in
> order to prevent them going insane and monopolizing a machine.  This
> is particularly useful if a server is the subject of a denial of
> service attack.
> 
> 2.  The Java VM needs hit its own memory limit before the operating
> decides to kills it, so that a proper log and stack trace can be
> produced.
> 
> 3.  There may be other untoward consequences of removing these limits:
> we don't think that the Java VM has ever been tested under such
> conditions.  It would take a very careful code audit to show that
> simply removing the checks doesn't violate assumptions in the VM.
> 
> Andrew.
> 
> 
> 2007-10-08  Andrew Haley  <aph at redhat.com>
> 
> 	* patches/icedtea-memory-limits.patch: New file.
> 	Set maximum PermGen space to 128M, MaxHeap to 512M.
> 	* Makefile.am (ICEDTEA_PATCHES): Add icedtea-memory-limits.patch.
> 
> --- openjdk/hotspot/src/share/vm/runtime/globals.hpp~	2007-09-27 08:46:16.000000000 +0100
> +++ openjdk/hotspot/src/share/vm/runtime/globals.hpp	2007-10-05 19:06:32.000000000 +0100
> @@ -2612,7 +2612,7 @@
>            "an OS lock")                                                     \
>                                                                              \
>    /* gc parameters */                                                       \
> -  product(uintx, MaxHeapSize, ScaleForWordSize(64*M),                       \
> +  product(uintx, MaxHeapSize, ScaleForWordSize(512*M),                       \
>            "Default maximum size for object heap (in bytes)")                \
>                                                                              \
>    product_pd(uintx, NewSize, 						    \
> --- openjdk/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp~	2007-09-27 08:45:59.000000000 +0100
> +++ openjdk/hotspot/src/cpu/x86/vm/c2_globals_x86.hpp	2007-10-05 19:02:37.000000000 +0100
> @@ -101,7 +101,7 @@
>  
>  // Heap related flags
>  define_pd_global(uintx, PermSize,    ScaleForWordSize(16*M));
> -define_pd_global(uintx, MaxPermSize, ScaleForWordSize(64*M));
> +define_pd_global(uintx, MaxPermSize, ScaleForWordSize(128*M));
>  
>  // Ergonomics related flags
>  define_pd_global(bool, NeverActAsServerClassMachine, false);
>