[
https://issues.apache.org/jira/browse/HBASE-10656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiroshi Ikeda updated HBASE-10656:
----------------------------------
Attachment: MyCounterTest.java
Added a revised test. Sorry, the previously added test prints wrong consumed
time. I created non-blocking logic, which should cause few context switches,
and I should have woken up at first the thread recording its start time.
Avoiding cache-line contention is one of the key words to improve performance,
but ironically we only detect it via failure of CAS with intentionally
colliding accesses. I think the size of cache-line differ from environments,
and if the estimate is small the chance of the detection reduces. For my
environment it seems the size of cache-line is 64bit * 8 and setting
MyCounter.Cat.CACHE_LINE_SCALE to 4 works well.
I used a well-spreaded hashcode using Thread.getId() under the assumption that
the ID is sequentially increasing, but that therefore reduces the chance of
failure of CAS, and that is bad if estimate size of the cache-line is small.
That's a dilemma.
> 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
> Priority: Minor
> Attachments: MyCounter.java, MyCounterTest.java, MyCounterTest.java
>
>
> 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.2#6252)
