Hello Peter, I was looking at this (thinking it would be a useful thing to benchmark, looking for possible improvements) and noticed that you rely on the hashed objects having a sensible value-dependent hashcode (as opposed to the default Object hashcode). Sadly, this seems not to be the case for MemberNames or for “Types”. I am sorely tempted to repair this glitch, not sure if it fits in the scope of the original bug, but there’s a lot to be said for future-performance-proofing.
David On 2014-11-09, at 7:55 AM, Peter Levart <peter.lev...@gmail.com> wrote: > Hi David, > > I played a little with the idea of having a hash table instead of packed > sorted array for interning. Using ConcurrentHashMap would present quite some > memory overhead. A more compact representation is possible in the form of a > linear-scan hash table where elements of array are MemberNames themselves: > > http://cr.openjdk.java.net/~plevart/misc/MemberName.intern/jdk.06.diff/ > > This is a drop-in replacement for MemberName on top of your jdk.06 patch. If > you have some time, you can run this with your performance tests to see if it > presents any difference. If not, then perhaps this interning is not so > performance critical after all. > > Regards, Peter
