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