RFR 8019375: Internal symbol table size should be tunable.

[Kirk Pepperdine]

Hi all,

I'm inclined to believe that there are performance benefits to be gained by being able to get statistics and then use those statistics to better size both the dictionary and the String table. The fact that we've not had ready access to these stats and settings in the field has at times compromised tuning efforts. The Code Cache is another example of where an auto-tunable hasn't quite worked out and that the ability to obtain measures and make adjustments would have been invaluable.

Kind regards,
Kirk Pepperdine

On 2013-08-29, at 1:55 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:

> Kevin,
> 
> Let's talk - I was serious about not asking customers to give values that tune our internal metadata sizes -
> we are potentially moving to different types of metadata or combining symbols with other things -- please
> modify to get a PredictedMaxVMStrings (other names welcome) - but to get a size from the customers that
> we then adopt metadata heuristics to.
> 
> thanks,
> Karen
> 
> On Aug 23, 2013, at 5:34 AM, Kevin Walls wrote:
> 
>> Hi,
>> 
>> I'd like to get reviews on this change to make the size of the symbol table tunable.  This can be a performance benefit to some apps, i.e. when the symbol table becomes overloaded (see PrintStringTableStatistics output).
>> 
>> This work here actually comes from Coleen.  I'm happy to take any further comments and update.
>> 
>> http://cr.openjdk.java.net/~kevinw/8019375/webrev.01/
>> http://bugs.sun.com/view_bug.do?bug_id=8019375
>> 
>> This uses SymbolTableSize as the tunable name.  (Another suggestion and possibile name, was PredictedMaxVMStrings to avoid talking explicity about the internal format.  Comments welcome!...)
>> 
>> Thanks
>> Kevin
>