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

[David Chase]

On 2014-11-04, at 5:07 AM, Peter Levart <peter.levart at gmail.com> 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