JDK-8037503 : Internal symbol table size should be limited in size
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_10
  • CPU: x86_64
  • Submitted: 2014-03-14
  • Updated: 2024-11-06
  • Resolved: 2016-09-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10Resolved
Related Reports
Duplicate :  
Description
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 ----------


Comments
Fixed by JDK-8078556
15-09-2016

We are already using range framework (JEP-245) to clamp the available values for runtime flags - already fixed.
15-09-2016