On 2014-11-03, at 3:09 PM, Peter Levart <[email protected]> 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
