Enis Soztutar commented on HBASE-7612:

According to javadoc, {{sum()}}  is not guaranteed to see an atomic snapshot. I 
think it is fine for most of our usage though. 

However, one case is sumThenReset(): 
   * Equivalent in effect to {@link #sum} followed by {@link
     * #reset}. This method may apply for example during quiescent
     * points between multithreaded computations.  If there are
     * updates concurrent with this method, the returned value is
     * <em>not</em> guaranteed to be the final value occurring before
     * the reset.
     * @return the sum
    public long sumThenReset() {

In some places in the patch, we are using sumThenReset() which means we maybe 
dropping some increments. Are these usages correct? 

Not sure why Counter is a declared public interface. Seems like an oversight. 
We can optionally replace the Counter internals to be a thin-layer on top of 
AtomicAdder if we are gonna keep the Counter class for BC. 

> [JDK8] Replace use of high-scale-lib counters with intrinsic facilities
> -----------------------------------------------------------------------
>                 Key: HBASE-7612
>                 URL: https://issues.apache.org/jira/browse/HBASE-7612
>             Project: HBase
>          Issue Type: Sub-task
>          Components: metrics
>    Affects Versions: 2.0.0
>            Reporter: Andrew Purtell
>            Assignee: Duo Zhang
>            Priority: Trivial
>             Fix For: 2.0.0
>         Attachments: HBASE-7612-v1.patch, HBASE-7612.patch
> JEP155 introduces a few new classes (DoubleAccumulator, DoubleAdder, 
> LongAccumulator, LongAdder) that "internally employ contention-reduction 
> techniques that provide huge throughput improvements as compared to Atomic 
> variables". There are applications of these where we are currently using 
> Cliff Click's high-scale-lib and for metrics.
> See http://openjdk.java.net/jeps/155

This message was sent by Atlassian JIRA

Reply via email to