[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-dev
Subject:    Re: RFR: 8201646: Introduce ReferenceDiscoverer interface
From:       Thomas Schatzl <thomas.schatzl () oracle ! com>
Date:       2018-04-18 12:24:24
Message-ID: 1524054264.6872.6.camel () oracle ! com
[Download RAW message or body]

Hi Per,

On Wed, 2018-04-18 at 14:06 +0200, Per Liden wrote:
> On 04/17/2018 02:54 PM, Thomas Schatzl wrote:
> > Hi Per,
> > 
> > On Tue, 2018-04-17 at 14:20 +0200, Per Liden wrote:
> > > Introduce ReferenceDiscoverer interface to allow for alternative
> > > ReferenceProcessor implementations. The current
> > > ReferenceProcessor
> > > implementation is built for STW operation, which is undesirable
> > > for
> > > low latency GCs.
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201646
> > > Webrev: http://cr.openjdk.java.net/~pliden/8201646/webrev.0
> > > 
> > 
> >    great, I also thought about introducing such an interface, but
> > hesitated because of the additional work :)
> 
> Thanks for reviewing!
> 
> I noticed one thing in my patch. To get the oop type I'm including 
> oop.hpp instead of oopsHierarchy.hpp. I'll fix this before pushing.
> 
> --- a/src/hotspot/share/gc/shared/referenceDiscoverer.hpp
> +++ b/src/hotspot/share/gc/shared/referenceDiscoverer.hpp
> @@ -27,7 +27,7 @@
> 
>   #include "memory/allocation.hpp"
>   #include "memory/referenceType.hpp"
> -#include "oops/oop.hpp"
> +#include "oops/oopsHierarchy.hpp"
> 
> > 
> > My question is, did you perform at least some cursory performance
> > checking because this adds a virtual call?
> 
> I did run specjbb2015 (which uses SoftRefs fairly heavily), 2
> iterations 
> with and 2 iterations without my patch. No measurable difference in 
> pause times.

 okay. Ship it.

Thomas
[prev in list] [next in list] [prev in thread] [next in thread]