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

[Doug Simon]

> 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())));

-Doug