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.kinn...@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
