RFR 8019375: Internal symbol table size should be tunable.

[Coleen Phillimore]

Kevin,
This looks good.  Thank you for following up on the SA issues, and 
resolving the issue of exposing the size of our symbol table by making 
this flag experimental.
Coleen

On 10/3/2013 5:21 AM, Kevin Walls wrote:
>
> Hi,
>
> Revisiting this after further testing, and marking the flag as 
> experimental as Karen suggested (usage will be 
> -XX:+UnlockExperimentalVMOptions -XX:SymbolTableSize=...).
>
> After removing an unnecessary method in the SA SymbolTable.java and 
> further testing, here's a webrev:
> http://cr.openjdk.java.net/~kevinw/8019375/webrev.02/
>
>
> Making the symbol table size tunable, and removing 
> SymbolTable::symbol_table_size in vmStructs.cpp, affects a 
> Serviceability Agent class, 
> agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java.
>
> There we reference the size we've removed, and that class has a method 
> getSymbolTableSize() which returns it, but that method is never 
> called.  My succesful testing including e.g the internal test suit 
> nsk/sajdi.nsk/sajdi is with that method removed.
>
> The SA SymbolTable has its own tableSize() which still does match the 
> size of the VM's own symboltable,
> after this change, and when using the new tunable to change the symbol 
> table size, without using the field I removed from vmStructs.
>
> How? 8-)  sun/jvm/hotspot/memory/SymbolTable initialises using the 
> vmStructs type information that describes the native BasicHashtable 
> (from src/share/vm/utilities/hashtable.hpp), and never needed the 
> field that directly stored the symbol table size.
>
> (I see we did something similar in StringTable for 6962930, including 
> removing the table size method in the SA class.)
>
> Thanks
> Kevin
>
>
>
>
> On 29/08/13 13:44, Kirk Pepperdine wrote:
>> 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
>