A DESCRIPTION OF THE REQUEST :
JDK-8019375 (Internal symbol table size should be tunable) added the " -XX:+UnlockExperimentalVMOptions -XX:SymbolTableSize=" option to allow the size of the symbol table (and string table) to be sized on the command line. It looks like there's a lower bound in minimumSymbolTableSize (and minimumStringTableSize), but it doesn't look like there is an upper bound. So I could say "-XX:+UnlockExperimentalVMOptions -XX:SymbolTableSize=1m" and create a symbol table that had 1 million chain heads. Allocating and clearing that could take a lot of time and space. On my machine using "-XX:SymbolTableSize=400m" gets me an hs_err log that says
Native memory allocation (malloc) failed to allocate 3355443200 bytes for AllocateHeap
VM state:not at safepoint (not fully initialized)
If I had more memory, I could say "-XX:SymbolTableSize=2147483647" and mount a denial of service attack against myself, because of paging, etc.
It would probably be good to have an upper bound on the size of the symbol table (and string table). Pick some number that you think is appropriate for the next 10 years, and have a friendly failure message that says exactly what to change. In particular, you shouldn't casually make -XX:SymbolTableSize= a product flag without such a check, because then bogus settings could cause the JVM to fail to start, or cripple a users machine.
JUSTIFICATION :
A command-line flag could have a bound to prevent mistakes and disasters.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
-XX:SymbolTableSize exceeds the upper bound of 1000000. Change "maximumSymbolTableSize" src/share/vm/utilities/globalDefinitions.hpp to a larger value.
ACTUAL -
The JVM fails to start with an hs_err log saying
Native memory allocation (malloc) failed to allocate 3355443200 bytes for AllocateHeap
VM state:not at safepoint (not fully initialized)
---------- BEGIN SOURCE ----------
$ ./jdk/9/bin/java -XX:+UnlockExperimentalVMOptions -XX:SymbolTableSize=400m -cp $Play/Java HelloWorld
with the usual HelloWorld.java is enough to show the problem.
---------- END SOURCE ----------
Native memory allocation (malloc) failed to allocate 3355443200 bytes for AllocateHeap
VM state:not at safepoint (not fully initialized)
If I had more memory, I could say "-XX:SymbolTableSize=2147483647" and mount a denial of service attack against myself, because of paging, etc.
It would probably be good to have an upper bound on the size of the symbol table (and string table). Pick some number that you think is appropriate for the next 10 years, and have a friendly failure message that says exactly what to change. In particular, you shouldn't casually make -XX:SymbolTableSize= a product flag without such a check, because then bogus settings could cause the JVM to fail to start, or cripple a users machine.
JUSTIFICATION :
A command-line flag could have a bound to prevent mistakes and disasters.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
-XX:SymbolTableSize exceeds the upper bound of 1000000. Change "maximumSymbolTableSize" src/share/vm/utilities/globalDefinitions.hpp to a larger value.
ACTUAL -
The JVM fails to start with an hs_err log saying
Native memory allocation (malloc) failed to allocate 3355443200 bytes for AllocateHeap
VM state:not at safepoint (not fully initialized)
---------- BEGIN SOURCE ----------
$ ./jdk/9/bin/java -XX:+UnlockExperimentalVMOptions -XX:SymbolTableSize=400m -cp $Play/Java HelloWorld
with the usual HelloWorld.java is enough to show the problem.
---------- END SOURCE ----------
- duplicates
-
JDK-8078556 Runtime: implement ranges (optionally constraints) for those flags that have them missing
- Resolved