[
https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792338#comment-13792338
]
Shai Erera commented on LUCENE-5272:
------------------------------------
After fixing the bug, I realized that the API of OBS is somewhat broken:
* setBits lets you set a {{long[] bits}}, but doesn't modify neither numBits
nor wlen.
** Nothing uses this method, so I'll nuke it. There's a ctor for that, so I
don't see the advantage.
* setNumWords has the same issues
** Nuke it too, one can call {{new OpenBitSet(other.getBits(), newNumWords)}}.
* get and fastGet don't work the same. If you create OBS(3) and call
get/fastGet(5) the result is different:
** fastGet trips the assertion
** get returns false
I'm not sure if get is wrong since if OBS allows growing, it's technically
correct to return false. But then, should it change numBits (because now the
app effectively 'grew' the array)? If it doesn't, then stupid code like
{{get(5); fastSet(5);}} fails because numBits isn't modified...
I don't know if we should fix it because then get() becomes an API which
modifies the OBS instance (which is unexpected).
Maybe we should get rid of numBits in OBS entirely? If someone called
ensureCapacity(5) and does set/fastSet(17), maybe it's ok if we sometimes
succeed in both? set() will grow the bits if needed, fastSet will trip an
AIOOBE which is OK I think .. if you want to use fastSet, make sure you call
ensureCapacity before.
In the meanwhile, I've discovered I can grow a FixedBitSet very easily by
allocating a new FBS instance, and FBS doesn't suffer from these
inconsistencies, so maybe I'll just use it for now to make progress, but would
still like to resolve the issues raised here.
One possible solution is to offer a convenient ctor to FBS, like
FixedBitSet(FixedBitSet other, int numBits) which will arraycopy the bits from
other. The only thing we add here is the FBS object allocation, vs OBS which
only grows the internal array, but I think that's not critical. If we do that,
then we can get rid of OBS entirely I think ... or remove all the fastXXX
methods and make it more like GrowableBitSet.
> OpenBitSet.ensureCapacity does not modify numBits
> -------------------------------------------------
>
> Key: LUCENE-5272
> URL: https://issues.apache.org/jira/browse/LUCENE-5272
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
> Reporter: Shai Erera
>
> It's a simple bug, reproduced by this simple test:
> {code}
> public void testEnsureCapacity() {
> OpenBitSet bits = new OpenBitSet(1);
> bits.fastSet(0);
> bits.ensureCapacity(5); // make room for more bits
> bits.fastSet(2);
> }
> {code}
> The problem is that {{numBits}} which is used only for assrets isn't modified
> by ensureCapacity and so the next fastSet trips the assert. I guess we should
> also fix ensureCapacityWords and test it too.
> I may not be able to fix this until Sunday though, so if anyone wants to fix
> it before (maybe it can make it into 4.5.1), feel free.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
