[9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames

[David Chase]

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.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:
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141112/2b3c571f/signature.asc>