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

harold seigel harold.seigel at oracle.com
Mon Oct 2 14:59:25 UTC 2017


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



More information about the hotspot-dev mailing list