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

[John Rose]

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.

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.

— John