hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-10656) high-scale-lib's Counter depends on Oracle (Sun) JRE, and also has some bug
Date Wed, 19 Oct 2016 18:11:58 GMT

    [ 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)

Mime
View raw message