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

[Christian Thalinger]

> On Nov 3, 2014, at 12:41 PM, David Chase <david.r.chase at oracle.com> wrote:
> 
> 
> On 2014-11-03, at 3:09 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
>> Hi David,
>> 
>> I was thinking about the fact that java.lang.invoke code is leaking into java.lang.Class. Perhaps, If you don't mind rewriting the code, a better code structure would be, if j.l.Class changes only consisted of adding a simple:
>> …
> 
>> This way all the worries about ordering of writes into array and/or size are gone. The array is still used to quickly search for an element, but VM only scans the linked-list.
>> 
>> What do you think of this?
> 
> I’m not sure.  I know Coleen Ph would like to see that happen.
> 
> A couple of people have vague plans to move more of the MemberName resolution into core libs.
> (Years ago I worked on a VM where *all* of this occurred in Java, but some of it was ahead of time.)
> 
> I heard mention of “we want to put more stuff in there” but I got the impression that already happened
> (there’s reflection data, for example) so I’m not sure that makes sense.
> 
> There’s also a proposal from people in the runtime to just use a jmethodid, take the hit of an extra indirection,
> and no need to for this worrisome jvm/java concurrency.
> 
> And if we instead wrote a hash table that only grew, and never relocated elements, we could
> (I think) allow non-synchronized O(1) probes of the table from the Java side, synchronized
> O(1) insertions from the Java side, and because nothing moves, a smaller dance with the
> VM.  I’m rather tempted to look into this — given the amount of work it would take to do the
> benchmarking to see if (a) jmethodid would have acceptable performance or (b) the existing
> costs are too high, I could instead just write fast code and be done.

…but you still have to do the benchmarking.  Let’s not forget that there was a performance regression with the first C++ implementation of this.

> 
> And another way to view this is that we’re now quibbling about performance, when we still
> have an existing correctness problem that this patch solves, so maybe we should just get this
> done and then file an RFE.
> 
> David
>