RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value

Mandy Chung mandy.chung at oracle.com
Thu May 30 00:49:35 UTC 2013

On 5/29/2013 3:44 PM, Brian Burkhalter wrote:
> On May 29, 2013, at 2:35 PM, Alan Bateman wrote:
>> It would be good to do a few experiments with -XX:AutoBoxCacheMax=<size> to make sure that bad values dp startup to fail, I expect they should.
> Yes, bad values do indeed cause startup to fail, for example:
> $ java -XX:AutoBoxCacheMax=1024\-Xmx2g HelloWorld
> Improperly specified VM option 'AutoBoxCacheMax=1024-Xmx2g'
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.

AutoBoxCacheMax is a signed integer argument and I think the VM will 
check if it contains any non-digit character but it doesn't validate for 
the range.  This could cause the VM to throw OOM:

java -XX:AutoBoxCacheMax=8888888888888888888
Error occurred during initialization of VM
java.lang.OutOfMemoryError: Java heap space
         at java.lang.Integer$IntegerCache.<clinit>(Integer.java:780)
         at java.lang.Integer.valueOf(Integer.java:808)
         at sun.misc.Signal.handle(Signal.java:169)
         at java.lang.Terminator.setup(Terminator.java:60)
         at java.lang.System.initializeSystemClass(System.java:1192)

The VM might truncate the specified AutoBoxCacheMax value as INTX_FORMAT
when it passes to the library:

    // Feed the cache size setting into the JDK
    char buffer[1024];
    sprintf(buffer, "java.lang.Integer.IntegerCache.high=" INTX_FORMAT, 

Probably best to file a bug too.

>> As regards setting the property directly (which was never the intention and is not supported) then the issue is that the property value is being parsed lazily. If you want to check it early then it requires parsing it in VM.saveAndRemoveProperties, that is the method that is called early in the initialization to stash away these properties.
> Whether this property is parsed early or lazily it seems like the fundamental question remains: given a non-parseable value does one fall back to the default or throw an exception and prevent VM startup?

Throwing an exception is a better solution that will make it easier to 
diagnose the problem.


More information about the core-libs-dev mailing list