In StackWalk API and LambdaForm, may be able to use the ResolvedMethodName, which is the java object wrapper on Method* directly rather than going through MemberName.  The ResolvedMethodName may need to add and cache the "name" field so it can be reused for StackWalk API.

From discussion with John:

>> I'm saying:
>>  - I want to plug those VMTarget thingies (or whatever they are called; see below) directly into MH's for faster invocation.
>
- I want to bring the Method* pointers as close as possible to the DirectMHs that use them, by planting a ResolvedMN directly into the DirectMH.

More snippets from John, but I'm afraid you'll have to fill in the rest.
"
The use case is
1. Create, as a POJO, an SMN with a given class/name/type/flags.  (It's resolvedData is null.)
2. Hand it to the JVM and ask the JVM to resolve it.
3. JVM finds (or makes) a ResolvedMemberName for the class/name/type in the SMN.  (Flags are ignored.)
4. JVM pokes it into the user-supplied POJO.
5. User continues with SMN, filled in with the JVM-supplied RMN.
6. User puts SMN (or maybe just RMN) into DMH, along with suitable linkToFoo code (depending on flags).
7. Some other user calls the DMH, causing call to linkToFoo with the SMN (or maybe just RMN).

The caching step I'm envisioning is:
5a. POJO code looks into newly-acquired RMN.  If it lacks name and/or type, it pokes those values into the RMN.

The caching doesn't help with symbolic lookup (steps 1-5 above).
But it does help with the case of a RMN that surfaces in other use cases:
A. Stack walking.
B. Cracking the RMN inside a DMH (MethodHandleInfo API).
C. Other low-level reflective queries, such as "find methods of this class".  (Future use case.)
"