> On Nov 3, 2014, at 12:41 PM, David Chase <david.r.ch...@oracle.com> wrote: > > > On 2014-11-03, at 3:09 PM, Peter Levart <peter.lev...@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 >
