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 20:32:19 UTC 2017

On 5/26/17 4:01 PM, John Rose wrote:

One more comment. I am not sure about this change:

int vmindex = javalanginvokeMemberName::vmindex(mname()); - if (vmtarget == NULL) { + bool havedefc = (javalanginvokeMemberName::clazz(mname()) != NULL); + + if (!havedefc) { THROWMSG(vmSymbols::javalangIllegalArgumentException(), "nothing to expand"); }

The point of the expander is that if a MN has only a RMN, then it can recover the rest of its guts. That's why the old code checked vmtarget, and new code should, I think, check the new 'method' for non-null.

I made this change so that field MemberName doesn't have to have a vmtarget, since now it's a ResolvedMethodName. For field MemberName, the "method" field is null.

I found that the clazz field is properly initialized in init_MemberName and never changes and is never null here, so that's why I check the clazz.

The point is that if you are holding an RMN, you can't "peek" into it unless you wrap a blank MN around it and request "expand". I hesitated to mention this earlier because I assume there was another reason for changing the logic of this method, but now after a full review I don't see the reason. Notice that RMN is now a completely opaque Java type, which is very good. But there needs to be a Java API for unpacking an RMN, and MN.expand is that API. This is where we came out in the end, and I think the havedefc changes are now just an artifact of an intermediate state. So, I suggest walking back the changes related to "havedefc", unless I've missed something here.

I thought we should add a different API for expanding a MemberName when you are holding a RMN, that isn't applicable for field MemberName.
That's why I made this change.

Coleen

— John

More information about the hotspot-dev mailing list