Cache MemberName data on initialization and resolution

[ThanHenderson]

State of Things

MemberNames -- specifically its vmtarget and vmindex members -- need to be fixed up on class redefinition. In the current implementation, each native J9Class instance has a memberNames which is a singly-linked list that holds weak references to all the MemberNames whose vmtarget is resolved one of the class' members.

Because we maintain a collection of weak references, a memberNames list node can become stale if the underlying MemberName is collected. To solve this potential memory leak scenario -- if there is no later call to redefineClassesCommon which will also force memberNames list's nodes to be cleaned up -- there is a finalize method on MemberName that indicates to the VM that a MemberName has become unreachable, and the that corresponding memberNames list node can be cleaned up the next time a node is added to the list.

The data reported here indicates that there can be many MemberNames that have the same vmtarget, suggesting that the MemberNames could share data representing their resolution.

Suggested New Approach

Adopt a cacheable structure to hold the the resolution data -- vmtarget and vmindex -- for a MemberName and intern those structures to share amongst MemberNames with the same resolution.

Such structure already exists on MemberName -- ResolvedMethodName -- but we don't use it; instead we inject vmtarget and vmindex directly into the MemberName.

A cache entry would hold a strong reference to a ResolvedMethodName, and on class redefinition, all entries in the cache corresponding to the class being redefined could be fixed up.

Considerations

1. Owner of the cache. Should we have a per-class hash table for storing ResolvedMethodNames owned by a J9Class? Or a single global cache that considers a class as a part of the key?
2. The extra level of indirection from the MemberName to the ResolvedMethodName to access the vmtarget and vmindex. I hadn't noticed any regressions in my initial benchmarking the use of ResolvedMethodName but some microbenchmarks may be necessary to quantify this.

Benefits

• Removes the finalize method -- which is deprecated -- from the MemberName Java class.
• Avoids the call to javaLookupMethod on cache hits during resolution.
• Better GC integration.
• Upper bound on number of cache entries for a class, whereas the MemberName list is unbounded.

This issues serves as a tracker for this work and a place for discussion on questions and about design details.

[ThanHenderson]

fyi,
VM: @babsingh @tajila
GC: @dmitripivkine @amicic
JIT: @jdmpapin

[babsingh]

MemberName (MN) Usage

Benchmark	Total MNs	Unique MNs	Duplication
Micro Benchmark (1 Million MHs)	186272	34	99.9%
HeapHogLoadTest	27918	992	96%
Libert Startup JDK11	3588	2287	36%
Liberty Throughput JDK11	1568	1042	34%
Liberty Throughput JDK21	3653	2317	37%
Nashorn MathTest	8182	4799	41%
Nashorn LoadJS	5838	3226	45%

MemberName.vmtarget points to the resolved J9Method, and it is used to evaluate if MemberNames are the same. Duplication refers to the percentage of MemberNames which are repeated.

[ThanHenderson]

Due to complications around fixing up and caching vmindex in the ResolvedMethodName objects, this work should be reconsidered when #17857 is resolved.