[
https://issues.apache.org/jira/browse/HBASE-10656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15589431#comment-15589431
]
Enis Soztutar commented on HBASE-10656:
---------------------------------------
bq. Revert HBASE-16146 or it would be better to replace all counters with
AtomicLong. Cache line contention is difficult to be detected on the language
level and we should stretch a net to catch the sign by chance through many
cache line contentions occur, even though the degradation is visible, and it
wastes to use the sign just once, throw away, and continue to suffer further
contentions.
No. AtomicLong is pretty bad for metrics usage. See the micro benchmarks in
various jiras, including HBASE-7612, HBASE-15222 and HBASE-16146.
bq. I am 99% sure that the JVM doesn't automatically generate padding for any
objects (other than the fact that all objects in memory are 8-byte aligned, I
think - i.e. they can only start at addresses 0, 8, 16 and so on).
Please read
http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007309.html.
I think the main problem is that we have A LOT of per-region metrics that are
latency histograms. These latency histograms create many many Counter /
LongAdder objects. We should get rid of per-region latencies and maybe look at
reducing the per-region metric overhead.
> high-scale-lib's Counter depends on Oracle (Sun) JRE, and also has some bug
> ----------------------------------------------------------------------------
>
> Key: HBASE-10656
> URL: https://issues.apache.org/jira/browse/HBASE-10656
> Project: HBase
> Issue Type: Bug
> Reporter: Hiroshi Ikeda
> Assignee: Hiroshi Ikeda
> Priority: Minor
> Fix For: 0.96.2, 0.98.1, 0.99.0
>
> Attachments: 10656-098.v2.txt, 10656-trunk.v2.patch, 10656.096v2.txt,
> HBASE-10656-0.96.patch, HBASE-10656-addition.patch, HBASE-10656-trunk.patch,
> MyCounter.java, MyCounter2.java, MyCounter3.java, MyCounterTest.java,
> MyCounterTest.java, PerformanceTestApp.java, PerformanceTestApp2.java,
> output.pdf, output.txt, output2.pdf, output2.txt
>
>
> Cliff's high-scale-lib's Counter is used in important classes (for example,
> HRegion) in HBase, but Counter uses sun.misc.Unsafe, that is implementation
> detail of the Java standard library and belongs to Oracle (Sun). That
> consequently makes HBase depend on the specific JRE Implementation.
> To make matters worse, Counter has a bug and you may get wrong result if you
> mix a reading method into your logic calling writing methods.
> In more detail, I think the bug is caused by reading an internal array field
> without resolving memory caching, which is intentional the comment says, but
> storing the read result into a volatile field. That field may be not changed
> after you can see the true values of the array field, and also may be not
> changed after updating the "next" CAT instance's values in some race
> condition when extending CAT instance chain.
> Anyway, it is possible that you create a new alternative class which only
> depends on the standard library. I know Java8 provides its alternative, but
> HBase should support Java6 and Java7 for some time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
