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

[coleen.phillimore at oracle.com]

On 5/22/17 11:23 PM, serguei.spitsyn at oracle.com wrote:
> Hi Coleen,
>
>
> I've finished reviewing, it looks great!

Thank you, Serguei!
>
> Just some nits.
>
> http://cr.openjdk.java.net/~coleenp/8174749.01/webrev/src/share/vm/classfile/javaClasses.cpp.frames.html
>
> A dot is missed at the end of the comment line 3259:
> 3258 // Add a reference to the loader (actually mirror because 
> anonymous classes will not have
> 3259 // distinct loaders) to ensure the metadata is kept alive
> 3260 // This mirror may be different than the one in clazz field.
>
ok.

> Dots are also missed in a couple of places in the 
> resolvedMethodTable.?pp comments:
>   resolvedMethodTable.hpp: L31, L35
>   resolvedMethodTable.cpp:
>       L130, L141 (L140 has an unnecessary dot)
>

Those comments didn't get fixed when I changed the code.  I wish the 
compiler would check this! I fixed them:

// Serially invoke removed unused oops from the table.
// This is done late during GC.
void ResolvedMethodTable::unlink(BoolObjectClosure* is_alive) {

...

// Serially invoke "f->do_oop" on the locations of all oops in the table.
void ResolvedMethodTable::oops_do(OopClosure* f) {
...

> resolvedMethodTable.cpp:
>
>   Values of the counters _oops_removed and_oops_counted are not used.
>   Is it a leftover from the debugging or there was a plan to log them?

They are used for counting and I added this logging message to the end 
of ResolvedMethodTable::unlink() to print them.

   log_debug(membername, table) ("ResolvedMethod entries counted %d 
removed %d",
                                 _oos_counted, _oops_removed);

>
>   195 // For each entry in MNT, change to new method
>
>   MNT should be RMT now. :)
>

Changed it.  Nice catch.

Thank you for reviewing this!
Coleen

>
> Thanks,
> Serguei
>
>
>
> On 5/17/17 09:01, coleen.phillimore at oracle.com wrote:
>> Summary: Add a Java type called ResolvedMethodName which is immutable 
>> and can be stored in a hashtable, that is weakly collected by gc
>>
>> Thanks to John for his help with MemberName, and to-be-filed RFEs for 
>> further improvements.  Thanks to Stefan for GC help.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8174749.01/webrev
>> open webrev at http://cr.openjdk.java.net/~coleenp/8174749.jdk.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8174749
>>
>> Tested with RBT nightly, compiler/jsr292 tests (included in rbt 
>> nightly), JPRT, jdk/test/java/lang/invoke, 
>> jdk/test/java/lang/instrument tests.
>>
>> There are platform dependent changes in this change. They are very 
>> straightforward, ie. add an indirection to MemberName invocations, 
>> but could people with access to these platforms test this out for me?
>>
>> Performance testing showed no regression, and large 1000% improvement 
>> for the cases that caused us to backout previous attempts at this 
>> change.
>>
>> Thanks,
>> Coleen
>>
>