[GitHub] [geode] upthewaterspout opened pull request #3922: GEODE-7085: Ensuring the bitset stays within BIT_SET_WIDTH

["upthewaterspout (GitHub)" <gi...@apache.org>]

Ensuring that when we call recordVersion on a RegionVersionHolder,
we appropriately move the bitSet to match the new version we are
recording, rather than trying to expand it. In particular, if new
version is greater than Integer.MAX_VALUE, we can't record than in out
integer indexed bit set.

This change rewrites addBitSetExceptions. The logic is now broken into a
BitSetExceptionIterator, which converts some or all of the bit set into
RVVException objects, and the logic to slide the bit set forward to a
new bitSetVersion.

Adding unit tests that show that large versions cause an
IndexOutOfBounds exception from recordGCVersion. Adding more unit tests
for the internal state of the bitset.

[ Full content available at: https://github.com/apache/geode/pull/3922 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] upthewaterspout commented on pull request #3922: GEODE-7085: Ensuring the bitset stays within BIT_SET_WIDTH

["upthewaterspout (GitHub)" <gi...@apache.org>]

Good point. I will add a check.

[ Full content available at: https://github.com/apache/geode/pull/3922 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] upthewaterspout closed pull request #3922: GEODE-7085: Ensuring the bitset stays within BIT_SET_WIDTH

["upthewaterspout (GitHub)" <gi...@apache.org>]

[ pull request closed by upthewaterspout ]

[ Full content available at: https://github.com/apache/geode/pull/3922 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] upthewaterspout commented on pull request #3922: GEODE-7085: Ensuring the bitset stays within BIT_SET_WIDTH

["upthewaterspout (GitHub)" <gi...@apache.org>]

Well, this is in the else clause - we we know that newVersion <= bitSetVersion+bitSet.size(). But maybe it would have been better to use Math.toIntExact here to validate that.

[ Full content available at: https://github.com/apache/geode/pull/3922 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] mcmellawatt commented on pull request #3922: GEODE-7085: Ensuring the bitset stays within BIT_SET_WIDTH

["mcmellawatt (GitHub)" <gi...@apache.org>]

Sorry for dumb questions, but is this cast safe?  Is it possible newVersion - bitSetVersion could be > Integer.MAX_VALUE e.g. if newVersion were Long.MAX_VALUE and bitSetVersion were 1, or do we know contextually that is not possible here?

[ Full content available at: https://github.com/apache/geode/pull/3922 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] mcmellawatt commented on pull request #3922: GEODE-7085: Ensuring the bitset stays within BIT_SET_WIDTH

["mcmellawatt (GitHub)" <gi...@apache.org>]

typo `maxmimumClearBit`

[ Full content available at: https://github.com/apache/geode/pull/3922 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] mcmellawatt commented on pull request #3922: GEODE-7085: Ensuring the bitset stays within BIT_SET_WIDTH

["mcmellawatt (GitHub)" <gi...@apache.org>]

larger

[ Full content available at: https://github.com/apache/geode/pull/3922 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org

[GitHub] [geode] upthewaterspout commented on pull request #3922: GEODE-7085: Ensuring the bitset stays within BIT_SET_WIDTH

["upthewaterspout (GitHub)" <gi...@apache.org>]

This assertion is a little stronger than toIntExact. We are asserting that the bitToSet is less than or equal to BIT_SET_WIDTH (around 1K).

[ Full content available at: https://github.com/apache/geode/pull/3922 ]
This message was relayed via gitbox.apache.org for notifications@geode.apache.org