A DESCRIPTION OF THE REQUEST :
The current method of setting a max heap size using -Xmx is not very userfriendly. The problem is that if the JVM can't reserve a block of that size, it will simply exit, even if you are using JNI to start the JVM. I saw that this is suppose to have been changed for version 5.0, but it still isn't very good since you need to create a loop and keep trying to create a JVM with smaller and smaller max heap size until you get it running. That won't even be possible if you aren't using your own application with JNI to start it, unless you add some option to the java.exe program.

The way this max heap works make me want to request two improvements:

1. Add an option to the JVM that specifies a max heap size, BUT if it is too big value the JVM itself will try to reserve as big heap as possible instead. Currently I have used this method outside the JVM to try and calculate an approximate max heap size, but the JVM will also resarve other unknow memory segments so some guesses are still necessary. I used this method on windows:

int getMaxJavaMemSize()
{
    int maxMem = 32;
    int step = 32;
    int testSize;
    void *p;

    while(step > 0)
    {
        testSize = maxMem + step;
        p = VirtualAlloc(NULL, testSize * 1024 * 1024, MEM_RESERVE, PAGE_NOACCESS);
        if(p != NULL)
        {
            VirtualFree(p, 0, MEM_RELEASE);
            maxMem = testSize;
        }
        else
        {
            step /= 2;
        }
    }

    // Subtract 80 meg which seems to give a number that works...
    return maxMem - 80;
}

If a similiar method was used in the JVM, things would be so much more userfriendly.


2. The second improvement I want to request is an option to use a smarter heap system that doesn't require a continous memory segment, but instead can use several chunks of memory depending on what address segments are available in the process address space.

The current method might work decently when running pure java and not using any external code or JNI calls, but we are using Java from another application that calls functions we made in a dll which then use JNI to call Java. This way of using Java can really show the weakness of the current heap system. The application we are working with will for example load a bunch of dll:s on different addresses, thus hugely decreasing the largest available segment, although the total unused address space might be much bigger. In some cases we could only allocate 150 MB heap, although maybe 800MB of the total address space was available.

It should be possible to implement an alternative heap reserving many smaller blocks instead of one large block if there isn't a block that is large enough. Ofcourse having many smaller blocks will mean that you can't allocate all of Java's heap for a single byte array, but normaly you will allocate many smaller objects, which shouldn't have a problem being put on different memory segments.


JUSTIFICATION :
The first improvement really should be implemented to make the JVM more userfriendly and won't require any trial and error to find a working max heap size.

The second suggestion is ofcourse much more work, but if you expect people to be able to use Java through JNI for all kinds of situations, the heap system should really be improved since the JVM can't expect to have full access to the entire address space.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
1. An option that sets a max heap size, but will allocate as big as possible if that size was too big. Should be easy to add to the current Java versions.

2. A completly new heap system, which would either replace the current or be selectable through an option to the JVM.

ACTUAL -
Currently the JVM exists if the max heap is bigger then the largest continous address range avaliable in the proecess. In version 5.0 it has atleast been slightly improved so the CreateJavaVM JNI function returns an exception instead.
###@###.### 2004-11-10 23:58:03 GMT