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

[Coleen Phillimore]

On 11/04/2014 05:07 AM, Peter Levart wrote:
> 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:
>>> …

Peter,

I agreed with your comment about java/lang/invoke things leaking into 
java/lang/Class.  I think this should be in another class with a pointer 
in java/lang/Class to it.   I'm adding jdk9-dev because I think the 
core-libs people may have an opinion about this.

On the JVM side, I suggested jmethodID as an alternate place to store 
the Method* to save the JVM from knowing how to inspect the contents of 
the MemberName type.   I'm not sure if that's the best solution since 
jmethodIDs leak memory and except for jvmti, the code assumes there 
aren't many.   But I would like us to think of a better solution.  My 
original idea was to save method->idnum() like we do with reflection but 
finding Method* from idnum can be complicated and apparently the code to 
to this is in assembly code for MethodHandles.

I would be surprised if the extra level of indirection at these calls 
would be a performance issue given all the code to added intern these 
things.

The idea that we should ship this because it works and file an RFE to 
rewrite it later is not acceptable to me.

Thanks,
Co9leen

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