RFR 8152271: MemberNameTable doesn't purge stale entries

[David Holmes]

Hi Coleen,

On 11/06/2016 12:55 AM, Coleen Phillimore wrote:
> Summary: Intern MemberNames in table instead of allocating new entries
>
> For degenerate case, we were leaking native code in the member name
> table.  Going with the suggested workaround, it was only a few more
> lines of code to intern MemberName and return the MemberName that was
> already in the table.

I guess I'm very surprised that these were not already being "cached" at 
some level (ie the Java level where all other reflection-like objects 
get cached)! I'm not familiar with the mechanics or j.l.invoke so was 
wondering where MemberName instances actually get created - because I'd 
like to understand how you get two distinct MemberName instances that 
compare equal in the first place?

Otherwise changes seem fine - though perhaps 
MemberNameTable::add_member_name should assert the member_name is not 
already present, just to confirm those intern==false cases are working 
as intended.

Thanks,
David
-----

> This has been performance tested to show no regression and works really
> well for the degenerate test case, even though the real percentage of
> reused MemberName seems quite small.
>
> Tested with all runtime nightly tests, tests in jdk/test/java/lang/invoke.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8152271.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8152271
>
> Thanks,
> Coleen