[
https://issues.apache.org/jira/browse/HBASE-14279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072528#comment-15072528
]
Hiroshi Ikeda commented on HBASE-14279:
---------------------------------------
The last patch contains a hash function coming from old JDK, and is it OK
around a license issue? Is there some reason JDK changes the logic of the hash
function and can we ignore it safely? I also slightly worry about there still
exists an other VM implementation that uses the old hash function, making our
internal maps completely waste.
As for other hash calculations, I'm not knowledgeable about MurmurHash but
using a strict calculation might waste. VM might prepare Object.hashCode with
poor dispersion because of performance, and hash functions in hash maps are
just for dispersion in lower bits, which are supposed to be extracted with some
lower bits mask. ConcurrehtHashMap.hash is exceptional because higher bits is
also used to select a segment, and I think it would pay additional performance
cost and it would not be appropriate in our case.
> Race condition in ConcurrentIndex
> ---------------------------------
>
> Key: HBASE-14279
> URL: https://issues.apache.org/jira/browse/HBASE-14279
> Project: HBase
> Issue Type: Bug
> Reporter: Hiroshi Ikeda
> Assignee: Heng Chen
> Priority: Minor
> Attachments: HBASE-14279.patch, HBASE-14279_v2.patch,
> HBASE-14279_v3.patch, HBASE-14279_v4.patch, HBASE-14279_v5.patch,
> HBASE-14279_v5.patch, HBASE-14279_v6.patch, HBASE-14279_v7.1.patch,
> HBASE-14279_v7.patch, LockStripedBag.java
>
>
> {{ConcurrentIndex.put}} and {{remove}} are in race condition. It is possible
> to remove a non-empty set, and to add a value to a removed set. Also
> {{ConcurrentIndex.values}} is vague in sense that the returned set sometimes
> trace the current state and sometimes doesn't.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
