RFR 8019375: Internal symbol table size should be tunable.

[Kevin Walls]

Thanks Coleen!

On 04/10/13 20:36, Coleen Phillimore wrote:
>
> 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
>>
>