JDK-8019375 : Internal symbol table size should be tunable.
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs25
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-06-28
  • Updated: 2014-11-18
  • Resolved: 2013-10-08
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-6610955 - SymbolTable and StringTable bucket arrays are probably too small
Description
To permit tuning for better performance when symbol table is likely to become overloaded, i.e. a higher bucket size as reported by PrintStringTableStatistics.
Comments
Please add this flag as experimental and set the expectation that this is going to go away from the start. The user-friendly is not the name, the user-friendly is giving users a way to give the vm a head's up on meaningful data, which we can for optimizations, rather than giving the vm a fixed size for the current vm metadata storage format. The goal is to a) make this dynamically resizable and b) we are likely to change the format of storing symbols for space and speed, so we don't want customers to be surprised in future when for instance there isn't a single symbol table, or it isn't a hash table or ... and the number they have been using is no longer meaningful.
11-09-2013
I don't know how much more user-friendly PredictedVMSymbolCount is relative to SymbolTableSize. Long term we can have the system dictionary size/ symbol table size and string table size ergonomically initialized based on a single parameter, like PredictedLoadedClassCount. Separate knobs for all three in the long run isn't very nice. I think Kevin should add SymbolTableSize for now because the performance team is already using it (as well as StringTableSize) and has had good results with it.
21-08-2013
We made a mistake in adding the StringTableSize - we should not be giving customers parameters that actually talk about internal metadata format. We should have used PredictedMaxVMStrings or something (see PredictedLoadedClassCount - which is experimental). Please add PredictedVMSymbolCount instead - this will allow us to play with internal metadata format and to have map any invalid values into a meaningful internal size - rather than for instance telling folks that a prime number is better ... thanks, Karen
21-08-2013