On 2014-11-04, at 5:07 AM, Peter Levart <[email protected]> wrote:
> 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?
It can’t be an identityHashMap, because we are interning member names.
In spite of my grumbling about benchmarking, I’m inclined to do that and try a
couple of experiments.
One possibility would be to use two data structures, one for interning, the
other for communication with the VM.
Because there’s no lookup in the VM data stucture it can just be an array that
gets elements appended,
and the synchronization dance is much simpler.
For interning, maybe I use a ConcurrentHashMap, and I try the following idiom:
mn = resolve(args)
// deal with any errors
mn’ = chm.get(mn)
if (mn’ != null) return mn’ // hoped-for-common-case
synchronized (something) {
mn’ = chm.get(mn)
if (mn’ != null) return mn’
txn_class = mn.getDeclaringClass()
while (true) {
redef_count = txn_class.redefCount()
mn = resolve(args)
shared_array.add(mn);
// barrier, because we are a paranoid
if (redef_count = redef_count.redefCount()) {
chm.add(mn); // safe to publish to other Java threads.
return mn;
}
shared_array.drop_last(); // Try again
}
}
(Idiom gets slightly revised for the one or two other intern use cases, but
this is the basic idea).
David
>>
>> 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
