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

[coleen.phillimore at oracle.com]

On 5/26/17 4:01 PM, John Rose wrote:
> One more comment.  I am not sure about this change:
>
>     int vmindex  = java_lang_invoke_MemberName::vmindex(mname());
> - if (vmtarget == NULL) {
> + bool have_defc = (java_lang_invoke_MemberName::clazz(mname()) != NULL);
> +
> + if (!have_defc) {
>       THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), "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 have_defc changes are now just an artifact of an 
> intermediate state.
>
> So, I suggest walking back the changes related to "have_defc", 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