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

[Peter Levart]

On 11/12/2014 07:27 PM, David Chase wrote:
> Hello Peter,
>
>> Sadly, this seems not to be the case for MemberNames or for “Types”.
> That statement is inoperative.  Mistakes were made.
> It’s compareTo that they lack.

Yes, I say your quite tricky implementation of MemberName.compareTo, 
based on hashCode(s), String representations, etc... The hash-table 
based interning does not need it though.

Regards, Peter

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141113/81e130de/attachment.html>