OK, we've redone our statistics on the full data sizes, and added
some additional statistics. Here are the total results:
Marking all possible fields in application as final
# of getfields 4,620,361,709
# of getfields of refs 1,013,942,180
# of non-final getfields of refs 282,328,996
# of non-final, non-null of same 147,060,687
# of getfields of final fields 1,820,379,686
# of instructions 37,327,868,137
# of bytes allocated 388,522,833
# of calls to alloc 8,983,341
# of sync methods & monitorenters 10,868,352
# of stores of refs 188,410,147
# of loads of refs 1,795,335,119
# of aaloads 776,274,578
# of nonfinal loads of refs 1,061,623,741
# of nonfinal nonnull loads of refs 796,568,754
Using original marking of final fields
# of non-final getfields of refs 979,091,755
# of non-final, non-null of same 843,427,617
# of getfields of final fields 34,821,542
# of nonfinal loads of refs 1,758,388,798
# of nonfinal nonnull loads of refs 1,492,946,424
The # of getfields of final fields, using the original marking,
is almost completely dominated by db. And there, it almostly
completely dominated by getfields on this$0 in nextElement of
java.util.Vector$1. Obvious and easy optimizations should eliminate
2/3's of those getfields,
So if we don't mark more fields as final, and we do the obvious optimizations
to eliminate redundant getfields, then only 0.3% of all getfields are
of final fields. Using Sanjay's numbers, putting a memory barrier in
front of all getfields of final fields should result in about a 0.6%
slowdown on Spec JVM98. So if we are want to enforce non-stale values
only for final fields, it doesn't look too expensive, particularly if
people don't start marking everything final.
Using the approach I suggested earlier isn't as promising. We only
get a factor of 4-6 savings over the numbers Sanjay got without
optimization. Now, we could probably use some optimization with the
new scheme, I'll be looking at that. Another issue is whether putting
the memory barrier after a getfield is more expensive than putting
one immediately before a getfield. I'll also be looking at that.
The full statistics are at:
http://www.cs.umd.edu/~pugh/java/memoryModel/JVM98stats.html
http://www.cs.umd.edu/~pugh/java/memoryModel/JVM98stats.xls
Bill
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:19 EDT