RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames
david.r.chase at oracle.com
Wed Nov 12 17:03:11 UTC 2014
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.
On 2014-11-09, at 7:55 AM, Peter Levart <peter.levart at 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:
> 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
More information about the core-libs-dev