RFR 8015395: NumberFormatException during startup if java.lang.Integer.IntegerCache.high set to bad value
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:
Error occurred during initialization of VM
java.lang.OutOfMemoryError: Java heap space
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
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