When using the "+XX:+UseISM" parameter, the user no longer has control
of how large the allocation of the heap is.
When we attempted to use this parameter at Sun's recommendation,
the JVM core dumped immediately (April 2001).
We reported the problem to the Sun representative who asked us to use
it and also to the Java Service group.
We received numerous "we're working on it" notes,
then a long period of silence.
As of about 8 months later (Jan 2002), we were informed that this
would be fixed in Version 1.4.0 which is to be released "shortly".
The net of the core dump is this: This pair of options
is designed to grab as
much memory as it can for the heap, and then lock it down.
It seems, this was only tested on machine with a memory size larger
than my 4GB.
There are no Sun SPECjbb2000 disclosures
where this ISM parameter is used
where the real memory of the system is less than 16GB of real memory.
The information below will show that the reason the JVM code is
failing on our system is that the "+XX:+UseISM" parameter
used with the "+XX:+AggressiveHeap" is trying
to allocate more memory than the system has to
allocate. Hence, an immediate core dump.
Our belief is that this pair of options was
specially formulated and only
intended for high performance benchmarking.
Your "actual performance" may be lower, as the saying goes.
The truss command shows there to be 4,156,555,264 bytes available
output from truss:
shmget(0, 4156555264, 0600|IPC_CREAT) Err#22 EINVAL
The only problem is that "available memory" is 4,136,960,000 as shown
in the system log entries below:
May 7 23:53:11 itamae unix: [ID 389951 kern.info]
mem = 4194304K (0x100000000)
May 7 23:53:11 itamae unix: [ID 930857 kern.info]
avail mem = 4136960000
If you do the math, the allocation is 19MB more than we have,
and the Java command core dumps.
19MB is actually not that much memory,
but you can't be just a "little bit" out of memory and still run!
Trying to Allocate = 4,156,555,264 (from truss - shmget)
Available Memory = 4,136,960,000 (from /var/adm/messages)
Overallocation = 19,595,264 bytes