RFR(14u): 8237375: SimpleThresholdPolicy misses CounterDecay timestamp initialization

[Langer, Christoph]

Hi Volker,

> -----Original Message-----
> From: Volker Simonis <volker.simonis at gmail.com>
> Sent: Mittwoch, 12. Februar 2020 09:57
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: Re: RFR(14u): 8237375: SimpleThresholdPolicy misses CounterDecay
> timestamp initialization
> 
> On Fri, Feb 7, 2020 at 1:46 PM Langer, Christoph
> <christoph.langer at sap.com> wrote:
> >
> > Hi Volker,
> >
> > thanks for having a look here.
> >
> > > Looks good except that I'd rather use:
> > >
> > > +    return ((os::javaTimeNanos() - _last_timestamp) /
> > > NANOUNITS_PER_MILLIUNIT) > CounterDecayMinIntervalLength;
> > >
> > > instead of:
> > >
> > > +    return ((os::javaTimeNanos() - _last_timestamp) / NANOUNITS *
> > > MILLIUNITS) > CounterDecayMinIntervalLength;
> > >
> > > because it looks clearer (and is exactly what nanos_to_millis() also does).
> >
> > You're right and I would have done that - but unfortunately
> NANOUNITS_PER_MILLIUNIT was only introduced with 8235741 and I don't
> want to pull this into my backport here.
> >
> > So, is the change for 11u also ok?
> >
> 
> I see. Then it's OK for me. You could use one more pair of parenthesis
> (i.e.  (((os::javaTimeNanos() - _last_timestamp) / NANOUNITS) *
> MILLIUNITS) to make the expression more clear, but I leave that up to
> you. No new review required from my side.

Thanks for the review. I'll do that.

Cheers
Christoph