FULL PRODUCT VERSION :
Java HotSpot(TM) Server VM (1.5.0_12-b04) for linux-x86, built on May
2 2007  customer :13:16 by java_re with gcc 3.2.1-7a (J2SE release)

ADDITIONAL OS VERSION INFORMATION :
Linux 2.6.9-55.0.2.ELsmp #1 SMP Tue Jun 12 17:58:20 EDT 2007 x86_64
libc:glibc 2.3.4 NPTL 2.3.4


A DESCRIPTION OF THE PROBLEM :
Even though MemoryPoolMXBean.setUsageThreshold() accepts a long argument, attempting to set to a large value (for example a very large heap) on a 64-bit OS but using a 32-bit VM results in:

java.lang.IllegalArgumentException: Invalid threshold value > max value of size_t
        at sun.management.MemoryPoolImpl.setUsageThreshold0(Native Method)
        at sun.management.MemoryPoolImpl.setUsageThreshold(MemoryPoolImpl.java:122)



ERROR MESSAGES/STACK TRACES THAT OCCUR :
ava.lang.IllegalArgumentException: Invalid threshold value > max value of size_t
        at sun.management.MemoryPoolImpl.setUsageThreshold0(Native Method)
        at sun.management.MemoryPoolImpl.setUsageThreshold(MemoryPoolImpl.java:122)

REPRODUCIBILITY :
This bug can be reproduced always.
Posted Date : 2008-01-21 16:26:57.0

N/A

It's a bug in the VM implementation that checks for the range within max integer value.
Posted Date : 2008-01-23 21:45:18.0

The problem is in 32bit jvm in setting threshold value greater than 3GB but less than 4GB. On 32bit vm max memory allowed is 4GB. So it setting threshold value is
limited to 4GB only.
Posted Date : 2008-11-25 20:19:41.0

http://hg.openjdk.java.net/jdk7/hotspot-svc/hotspot/rev/2494ab195856
Posted Date : 2008-12-16 01:10:03.0

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/2494ab195856
Posted Date : 2008-12-17 18:57:19.0

This bug impacts setCollectionThreshold() as well and has a severe impact on this functionality.

The bug is clear and is in jmm_SetPoolThreshold() in management.cpp.  Therein threshold is compared to max_intx.

It is quite clear that max_intx is a *signed* quantity whereas this needs to be an unsigned quantity (ala max_uintx).  I didn't follow through all the typedefs to see if this is really correct under 64-bit operation, as suggested by a comment above this code which states that intx and uintx are 64-bits wide in that case.

This *desparately* needs to be fixed as it does not allow setting of these thresholds to anything greater than 2GB in a 32-bit JVM, thus greatly limiting the utility of this functionality.

Note that this bug is still quite present in Java 6 Update 6.

I really need a fix for this both in Java 5 and Java 6.

Having MemoryPool.set*Threshold() functionality fail for thresholds above 2GB in a 32-bit JVM severely marginalizes this entire functionality for any 32-bit server JVM usage -- as in this case one is very, very likely pushing the heap over 2GB if one has any concerns about memory thresholds.