[
https://issues.apache.org/jira/browse/LUCENE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801195#action_12801195
]
Dawid Weiss commented on LUCENE-2216:
-------------------------------------
Hi Yonik,
This class is not thread-safe anyway (there are no memory barriers of any kind
anywhere in the code).
>From a single-thread perspective, yes, you are modifying the internal state of
>this object, but it's not really affecting anything other than possibly
>speeding up further interaction with this object (any other operation no
>OpenBitSets is affected by the value inside wlen).
Your patch also solves the issue, of course. I just don't see the point in
_not_ updating wlen since you're scanning through memory anyway... The
implementation of OpenBitSet is different in this regard to java.util.BitSet,
which always maintains the last non-empty index. I've been thinking about it a
bit and there are pros and cons to both implementations, but lazily moving wlen
when memory is scanned anyway seems like a better alternative than keeping wlen
unnecessarily large (which affects ORs, ANDs and other set operations).
To me this implementation cannot be used in a multi-threaded application
anyway, am I wrong here?
D.
> OpenBitSet#hashCode() may return false for identical sets.
> ----------------------------------------------------------
>
> Key: LUCENE-2216
> URL: https://issues.apache.org/jira/browse/LUCENE-2216
> Project: Lucene - Java
> Issue Type: Bug
> Components: Other
> Affects Versions: 2.9, 2.9.1, 3.0
> Reporter: Dawid Weiss
> Priority: Minor
> Attachments: LUCENE-2216.patch, openbitset.patch
>
>
> OpenBitSet uses an internal buffer of long variables to store set bits and an
> additional 'wlen' index that points
> to the highest used component inside {...@link #bits} buffer.
> Unlike in JDK, the wlen field is not continuously maintained (on clearing
> bits, for example). This leads to a situation when wlen may point
> far beyond the last set bit.
> The hashCode implementation iterates over all long components of the bits
> buffer, rotating the hash even for empty components. This is against the
> contract of hashCode-equals. The following test case illustrates this:
> {code}
> // initialize two bitsets with different capacity (bits length).
> BitSet bs1 = new BitSet(200);
> BitSet bs2 = new BitSet(64);
> // set the same bit.
> bs1.set(3);
> bs2.set(3);
>
> // equals returns true (passes).
> assertEquals(bs1, bs2);
> // hashCode returns false (against contract).
> assertEquals(bs1.hashCode(), bs2.hashCode());
> {code}
> Fix and test case attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
