[
https://issues.apache.org/jira/browse/HBASE-7612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15501809#comment-15501809
]
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():
{code}
* 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() {
{code}
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
(v6.3.4#6332)
