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

[Peter Levart]

On 11/03/2014 09:41 PM, David Chase 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.)

Hi David,

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

Reflection is an API that is rooted in j.l.Class. If the plans are to 
move some of the java.lang.invoke public API to java.lang package (into 
the j.l.Class,  ...), then this is understandable.

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

The linked list of MemberName(s) is also worry-less and doesn't need an 
extra indirection via jmethodid. Does the hit of extra indirection occur 
when invoking a MethodHandle?

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

Are you thinking of an IdentityHashMap type of hash table (no 
linked-list of elements for same bucket, just search for 1st free slot 
on insert)? The problem would be how to pre-size the array. Count 
declared members?

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

Perhaps, yes. But note that questions about JMM and ordering of writes 
to array elements are about correctness, not performance.

Regards, Peter

>
> David
>