Good catch Jeff! I think it's possible that I missed the flag cleanup case
here, but it's also possible that I got lucky and it worked anyway.
That said, I think the observation in the other email thread/commit is key
here. I will reply back in that one, but it seems like this can all be
simplified using Jeff's idea with an amortized O(1) solution by caching a
known non-stale entry in the queue, and thus becomes obsolete. I will post
a new patchset when the discussion slows down.

As for general flag management, I will spend some more time thinking about it.
I don't fully trust static code analysis to work, but some cheap assertion
based model might give a nice trade-off.

Thanks for all the feedback!
- Kristofer

On Mon, 25 May 2026 at 09:17, Junio C Hamano [off-list ref] wrote:

Kristofer Karlsson [off-list ref] writes:

quoted

While doing the audit I noticed that reasoning about flag safety is
currently entirely manual. Would there be interest in something more
systematic (e.g. runtime registration/assertion, dynamic allocation or static
analysis of flag usage)? I have some local work on that already, but I was
not sure if this was something worth spending time on or not.

If there weren't existing code that are so tied to their current
uses of fixed flag bits and assumption that nobody else uses these
bits outside their intended use, I'd love to have any of these.
Uncolliding and unbounded number of usable bits per object that are
*fast* to access would be good (and commit-slab was an attempt to
introduce a framework that can be used as the basis for such a
system).  Independent of that, if we can statically analyze the uses
of these bits to prove that the same flag bits are never used at the
same time for colliding purposes, that would really be valuable.