[
https://issues.apache.org/jira/browse/LUCENE-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801230#action_12801230
]
Dawid Weiss edited comment on LUCENE-2216 at 1/16/10 5:26 PM:
--------------------------------------------------------------
This is not entirely what I had in mind (it's not cache, but HotSpot
optimisation), but similar situation applies (the value of the field that's
never modified from the perspective of the current thread is never re-read).
{code}
public class Example10 {
private static Holder holder;
public static void startThread() {
new Thread() {
public void run() {
try { sleep(2000); } catch (Exception e) { /* ignore */ }
holder.ready = true;
System.out.println("Setting ready to true.");
}
}.start();
}
public static void main(String [] args) {
holder = new Holder();
startThread();
while (!holder.ready) {
// Do nothing.
}
System.out.println("I'm ready.");
}
}
class Holder {
public boolean ready;
}
{code}
If you run it with -server, it will (should... or does on two machines I own)
deadlock. Client mode and interpreted mode are not optimized, so it passes.
was (Author: dawidweiss):
This is not entirely what I had in mind (it's not cache, but HotSpot
optimisation), but similar situation applies (the value of the field that's
never modified from the perspective of the current thread is never re-read).
{code}
public class Example10 {
private static Holder holder;
public static void startThread() {
new Thread() {
public void run() {
try { sleep(2000); } catch (Exception e) { /* ignore */ }
holder.ready = true;
System.out.println("Setting ready to true.");
}
}.start();
}
public static void main(String [] args) {
holder = new Holder();
startThread();
while (!holder.ready) {
// Do nothing.
}
System.out.println("I'm ready.");
}
}
class Holder {
public boolean ready;
}
{/code}
If you run it with -server, it will (should... or does on two machines I own)
deadlock. Client mode and interpreted mode are not optimized, so it passes.
> 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
