RFR 8019375: Internal symbol table size should be tunable.

[Kevin Walls]

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