RFR (L) 8174749: Use hash table/oops for MemberName table

[coleen.phillimore at oracle.com]

On 5/26/17 5:48 AM, Doug Simon wrote:
>> On 26 May 2017, at 02:04, John Rose <john.r.rose at oracle.com> wrote:
>>
>> On May 17, 2017, at 9:01 AM, coleen.phillimore at oracle.com wrote:
>>> Summary: Add a Java type called ResolvedMethodName which is immutable and can be stored in a hashtable, that is weakly collected by gc
>> I'm looking at the 8174749.03/webrev version of your changes.
>>
>> A few comments:
>>
>> In the JVMCI changes, this line appears to be incorrect on 32-bit machines:
>>
>> +                vmtargetField = (HotSpotResolvedJavaField) findFieldInClass(methodType, "vmtarget", resolveType(long.class));
>>
>> (It's a pre-existing condition, and I'm not sure if it is a problem.)
> Given that JVMCI does not support any 32-bit platforms currently, it should not be a problem in practice. The field lookup would also fail-fast when adding 32-bit support.
>
> That said, we can take this opportunity to make it portable by replacing:
>
> +                vmtargetField = (HotSpotResolvedJavaField) findFieldInClass(methodType, "vmtarget", resolveType(long.class));
>
> with:
>
> +                vmtargetField = (HotSpotResolvedJavaField) findFieldInClass(methodType, "vmtarget", resolveType(HotSpotJVMCIRuntime.getHostWordKind().toJavaClass())));

I can make this change.  I hope it works after I cut and paste this :)
Coleen

>
> -Doug
>