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

[coleen.phillimore at oracle.com]

On 5/23/17 10:10 AM, coleen.phillimore at oracle.com wrote:
>
>
> 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);

Make that _oops_counted, _oops_removed.  This is useful logging.
thanks,
Coleen
>
>>
>>   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
>>>
>>
>