[aliszka]

Both of sroar's reallocation sites grew a buffer by its own capacity, which is right for a small bitmap and wrong for a large one. This puts one shared grownCap behind both, keeps the old rule below a size limit and takes a fraction of the grown size above it. It also exports capInBytes as CapInBytes.

Motivation

A bitmap grown by repeated Or of monotone doc IDs — weaviate's in-memory roaringset range representation, and any accumulator built that way — ends up carrying close to a second copy of itself in slack. That slack is resident for as long as the process runs, while the copying that avoids it is a one-off at build time.

Approach

Below growDoubleLimit the arithmetic is byte-identical to the old cap + max(cap, need), which is what lets the package's existing capacity assertions stand unchanged.

The limit branches on the old capacity, not on the grown size, so a fresh bitmap absorbing one large Or still lands on an exact fit. That is deliberate: roaringset.Condense is exactly that shape and its doc comment says the minimal size is the point. A bitmap that keeps accumulating instead pays one copy for it at the next merge.

The slack has no floor. An earlier form floored it at the limit so the handoff from doubling stayed continuous, which made every bitmap just past the limit carry a limit-sized slack and turned the band above it into arithmetic growth. Dropping the floor costs monotonicity of grownCap in cp — a buffer just under the limit grows larger than one just over it — which is harmless for a single buffer, whose capacity only ever increases.

Key areas for review

• bitmap.go grownCapWith — the two arms and the step down at the limit
• bitmap_opt.go expandConditionally — check the new capacity still covers ln+sizeKeys+sizeContainers
• bitmap_test.go TestGrownCap — the rows either side of the limit are what pin the discontinuity

Risks

• Building a large bitmap copies more. That is a one-off against slack that stays resident, and BenchmarkGrownCap sweeps both constants so the balance can be re-decided rather than re-derived.
• roaringset/binary_search_tree.go documents that sroar grows by doubling, and its heap-ratio test bounds slack accordingly. Every shape that test builds stays below the limit, so the bounds hold; the prose wants fixing when weaviate bumps sroar.

Testing

TestGrownCap covers both arms, the boundary and the exact-fit case. TestGrowthKeepsSlack and TestGrowthKeepsSlackOnSet drive the two growth sites end to end through Or and Set; both fail against the old formula. The package's existing capacity assertions are unchanged.

Unrelated, found while reviewing: FillUp computes requiredContainersCount * maxContainerSize in int, which wraps on a 32-bit build. Recorded in the findings inbox, not fixed here.

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca