8162795: RFR: [REDO] MemberNameTable doesn't purge stale entries

[Kevin Walls]

Hi Serguei - great, I've corrected that in the same location.

Thanks
Kevin


On 21/02/2017 03:13, serguei.spitsyn at oracle.com wrote:
> Hi Kevin,
>
> This looks good but one comment needs to be corrected:
>
> http://cr.openjdk.java.net/~kevinw/8162795/webrev.00/src/share/vm/prims/methodHandles.cpp.udiff.html 
>
>
> + // This is linear because these because these are short lists. The 
> "because these" repeated twice.
>
>
>
> Thanks,
> Serguei
>
>
> On 2/20/17 07:24, Kevin Walls wrote:
>> Hi,
>>
>> This is a review request for:
>> [REDO] MemberNameTable doesn't purge stale entries
>> https://bugs.openjdk.java.net/browse/JDK-8162795
>>
>> For certain apps, such as those with heavy use of the JavaScript 
>> engine, the MemberNameTable and its weak references can introduce 
>> considerable GC overhead.  In some cases GC cannot keep up with the 
>> activity and collection times continually increase.  This is a 
>> regression in jdk8 or later, compared to e.g. jdk7.
>>
>> The change in 8152271:
>> https://bugs.openjdk.java.net/browse/JDK-8152271
>> MemberNameTable doesn't purge stale entries
>>
>> ...fixes this, but that was reverted from 9 due to a regression in a 
>> microbenchmark.  While that benchmark is a concern, more serious is 
>> the regression currently out there for certain apps when moving up to 
>> JDK 8 or 9.  Adding back the change in 8152271 fixes this.
>>
>> Re-applying the original change from 8152271 by Coleen still works, 
>> with one copyright date fixup.  A webrev is:
>>
>> http://cr.openjdk.java.net/~kevinw/8162795/webrev.00/
>>
>> Plan is to re-integrate the 8152271 change in 9 (this request), and 
>> backport to 8.  Meanwhile, a better solution for MemberNameTable in 
>> jdk10 is being pursued in 
>> https://bugs.openjdk.java.net/browse/JDK-8174749
>>
>> Thanks
>> Kevin
>>
>>
>