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

[David Chase]

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.

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

-------------- 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/20141103/541e18ac/signature.asc>