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

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Fri May 26 14:52:49 UTC 2017

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

More information about the hotspot-dev mailing list