RFR (L) 8186777: Make Klass::_java_mirror an OopHandle

[coleen.phillimore at oracle.com]

Thank you, Harold!
Coleen

On 10/2/17 10:59 AM, harold seigel wrote:
> Hi Coleen,
>
> The hs runtime changes look good.
>
> Thanks! Harold
>
>
> On 9/28/2017 5:36 PM, coleen.phillimore at oracle.com wrote:
>>
>> Thank you to Stefan Karlsson offlist for pointing out that the 
>> previous .01 version of this webrev breaks CMS in that it doesn't 
>> remember ClassLoaderData::_handles that are changed and added while 
>> concurrent marking is in progress.  I've fixed this bug to move the 
>> Klass::_modified_oops and _accumulated_modified_oops to the 
>> ClassLoaderData and use these fields in the CMS remarking phase to 
>> catch any new handles that are added.   This also fixes this bug 
>> https://bugs.openjdk.java.net/browse/JDK-8173988 .
>>
>> In addition, the previous version of this change removed an 
>> optimization during young collection, which showed some uncertain 
>> performance regression in young pause times, so I added this 
>> optimization back to not walk ClassLoaderData during young 
>> collections if all the oops are old.  The performance results of 
>> SPECjbb2015 now are slightly better, but not significantly.
>>
>> This latest patch has been tested on tier1-5 on linux x64 and windows 
>> x64 in mach5 test harness.
>>
>> http://cr.openjdk.java.net/~coleenp/8186777.02/webrev/
>>
>> Can I get at least 3 reviewers?  One from each of the compiler, gc, 
>> and runtime group at least since there are changes to all 3.
>>
>> Thanks!
>> Coleen
>>
>>
>> On 9/6/17 12:04 PM, coleen.phillimore at oracle.com wrote:
>>> Summary: Add indirection for fetching mirror so that GC doesn't have 
>>> to follow CLD::_klasses
>>>
>>> Thank you to Tom Rodriguez for Graal changes and Rickard for the C2 
>>> changes.
>>>
>>> Ran nightly tests through Mach5 and RBT.   Early performance testing 
>>> showed good performance improvment in GC class loader data 
>>> processing time, but nmethod processing time continues to dominate. 
>>> Also performace testing showed no throughput regression.   I'm 
>>> rerunning both of these performance testing and will post the numbers.
>>>
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186777
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186777.01/webrev
>>>
>>> Thanks,
>>> Coleen
>