RFR (L) 8186777: Make Klass::_java_mirror an OopHandle
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Thu Sep 28 21:36:23 UTC 2017
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