On Tue, 21 Dec 2021 17:08:26 GMT, yosbits <d...@openjdk.java.net> wrote:
>> What about the first part of my question? Have you looked at the set logic >> to ensure that `size` is being invalidated in all places it should be. The >> `set(int index, int... indices)` method does not directly invalidate `size`. >> If that method unconditionally set `size = -1`, it would be easier to prove >> that there are no missed cases. > > This is a cache of the cardinality method of BitSet, not Lazy evaluation. It > sets invalidity (-1) in the method call that changes the bit. This could be a > subclass of BitSet to make the code more readable. This patch does not > subclass BitSet because there is no case where it is used in the same way. > > If you subclass it, you can probably reduce the number of calls to > cardinality to zero if you calculate it wisely instead of simply setting > invalid. The patch does not take this challenge for readability reasons. A cache that's manually invalidated and then validated when needed is a form of lazy evaluation. The main point, regardless of how you name it, is to ensure that every call that modifies the underlying BitSet invalidates the size. If it does, and it can be proven to do so, then that's sufficient. ------------- PR: https://git.openjdk.java.net/jfx/pull/673
