RFR (L) 8174749: Use hash table/oops for MemberName table (original) (raw)
Doug Simon doug.simon at oracle.com
Fri May 26 09:48:29 UTC 2017
- Previous message: RFR (L) 8174749: Use hash table/oops for MemberName table
- Next message: RFR (L) 8174749: Use hash table/oops for MemberName table
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: RFR (L) 8174749: Use hash table/oops for MemberName table
- Next message: RFR (L) 8174749: Use hash table/oops for MemberName table
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]