RFR (S) 8014262 - more footprint info for PrintStringTableStatistics
Ioi Lam
ioi.lam at oracle.com
Thu May 9 11:52:56 PDT 2013
Please review:
http://cr.openjdk.java.net/~iklam/8014262/table_stats_001/
Bug: PrintStringTableStatistics should include more footprint info
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014262
https://jbs.oracle.com/bugs/browse/JDK-8014262
Summary of fix:
StringTable and SymbolTable take up significant footprint (about
4.5% of total footprint of Eclipse). The old output doesn't has very
little info
---OLD---
Number of buckets : 20011
Average bucket size : 8
Variance of bucket size : 8
Std. dev. of bucket size: 3
Maximum bucket size : 25
StringTable statistics:
Number of buckets : 60013
Average bucket size : 0
Variance of bucket size : 0
Std. dev. of bucket size: 1
Maximum bucket size : 6
I modified it to print these:
---NEW---
SymbolTable statistics:
Number of buckets : 20011 = 160088 bytes, avg 8.00
Number of entries : 166724 = 4001376 bytes, avg 24.00
Number of literals : 166724 = 7943576 bytes, avg 47.65
Total footprint : = 12105040 bytes
Average bucket size : 8.332
Variance of bucket size : 8.308
Std. dev. of bucket size: 2.882
Maximum bucket size : 25
StringTable statistics:
Number of buckets : 60013 = 480104 bytes, avg 8.00
Number of entries : 25822 = 619728 bytes, avg 24.00
Number of literals : 25822 = 2458696 bytes, avg 95.22
Total footprint : = 3558528 bytes
Average bucket size : 0.430
Variance of bucket size : 0.435
Std. dev. of bucket size: 0.659
Maximum bucket size : 6
Templave vs virtual function:
Part of this code is kind of ugly, in hashtable.cpp:
...void Hashtable<T, F>::dump( ...) {
...
for (HashtableEntry<T, F>* e = table->bucket(i);
264 e != NULL; e = e->next()) {
265 count++;
266 literal_bytes += literal_size(e->literal());
267 }
literal_size() is magically matched by the templates to call one of
these
in hashtable.hpp:
template <class T, MEMFLAGS F> class Hashtable : public
BasicHashtable<F> {
...
286 static int literal_size(Symbol *symbol);
287 static int literal_size(oop oop);
288 static int literal_size(ConstantPool *cp) {Unimplemented();
return 0;} // currently not used
289 static int literal_size(Klass *k) {Unimplemented(); return
0;} // currently not used
I am wondering if I should change this to be a virtual function
instead.
However, none of the current hashtable code uses virtual functions.
So it
is considered OK to have a virtual function like this:
template <class T, MEMFLAGS F> class Hashtable : public
BasicHashtable<F> {
public:
virtual int literal_size(T) {return 0;}
...
}
class SymbolTable : public Hashtable<Symbol*, mtSymbol> {
public:
virtual int literal_size(Symbol* sym) {return sym->size() *
HeapWordSize;}
...
}
Any suggestions?
Tests:
This code path is not taken in regular JVM executions, so
I just ran JPRT to make sure the code builds on all platforms.
Tested manually on Linux and Solaris:
$ java -XX:+PrintStringTableStatistics -version
Thanks
- Ioi
More information about the hotspot-runtime-dev
mailing list