JDK-7122219 : Passed StringTableSize value not verified
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6u30
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-12-16
  • Updated: 2014-07-21
  • Resolved: 2012-11-12
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 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
JDK-8002329 - Replace -XX:StringTableSize flag with -XX:PredictedInternedStringCount
Description
There is no verification for value passed as argument for -XX:StringTableSize option:
1) value with suffix related to memory size (k, m, g) may be passed, but StringTableSize stands for number of records in table, not for memory size;
2) if amount of memory that should be allocated for string table bigger than amount of memory available for allocation, then VM will be crashed.

Issues found in JDK 1.6.0_30 b22, JDK 1.7.0 b136.

Steps to reproduce:
1) ssh ###@###.###
2) /set/stt/newroot/vmsqe/gtee/bin/jdk install_bundles -srcdirbase /set/stt/newroot/jdk -release 1.6.0_30 -build b22_j4b -arch linux-i586 -jdkrename false
3) /export/jdk/jdk1.6.0_30/bin/java -Xmx2g -Xms2g -XX:StringTableSize=1
4) /export/jdk/jdk1.6.0_30/bin/java -XX:StringTableSize=1g
5) /export/jdk/jdk1.6.0_30/bin/java -XX:StringTableSize=1000000000
Comments
I don't see how a user can reasonably know the predicted interned string count - the VM/libraries intern thousands of strings. Plus how long is a string? Even if you knew the count the VM doesn't know the size. Passing in an actual memory size for the table seems a reasonable approach. From the report the current StringTableSize variable is misleadingly named (number of records?), and not sanity checked. Such a setting should be a suggestion to the VM for the amount of space to use for the table. Just like eg stacksize, the VM has to impose a reasonable minimum that ensures the VM can at least initialize. The table should then expand dynamically as needed or trigger an OOME if it can't - rather than crashing.
09-10-2012
We should not have the user passing in a size for an internal data structure, nor needing to know how these are stored internally. Instead of StringTableSize we should have the user pass in the PredictedInternedStringCount Then the VM can appropriately allocate the internal metadata to optimize for this count.
08-10-2012