Re: jk/tag-contains: stalled

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 5, 2010, 20:53 UTC
Message-ID: <7vd3twdbny.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100805190653.GA2942@sigill>

Jeff King <peff@peff.net> writes:

> Oops, thanks, I had forgotten that the marks needed to be addressed.
> Should I be introducing new flags? We have 27 flag bits, but I would
> hate to waste 2 of them.

In the longer term it would be not just nice but necessary for us to come up with a scheme where different codepaths can "allocate bits from object flags", without having to fear stepping on each other's toes. Some possible approaches off the top of my head are:

 - Extend "struct object" by another uint64_t to give it 64 more bits?
   That would make the minimum object size from 24 bytes to 32 bytes and
   during a pack-object session we would keep a lot of objects (not just
   commits but trees and blobs) in core, so we probably would not want to
   do this.

 - Extend "struct commit" by another uint32_t?  Currently a "struct
   commit" is 72 bytes on x86_64 (there is an unfortunate 4-byte padding
   gap between indegree and date), and 48 bytes on i386 and this would
   enlarge the latter to 52 bytes (this comes free on 64-bit archs).

   As we need a lot more bits on commits than on other objects
   (e.g. left-right do not need to be placed on trees or blobs), this
   approach might be more space efficient.

 - Use one bit in the current flags section to signal "extended flag bits
   present on this object", and have a separate hashtable for minority
   objects that have that bit set?  This would work only for flag bits
   that are rarely used (otherwise the secondary hashtable will be full of
   objects and per-object overhead will kill us).

 - Migrate some users of flag bits that only mark small miniroty of
   commits to use dedicated hashtable to free their bits [*1*].  I don't
   know if there are candidates for doing this offhand.  Just uttering it
   as an idea.

Independent of this issue, I suspect that we might want to fold object.used into the general set of flags---it is only used by fsck as far as I remember.

[Footnote]

*1* Also we would want to do something similar to the commit.util field so that more than one utility libraries can attach their own stuff to each commit. It _might_ make sense to instead get rid of commit.util and migrate the users to a separate "one object hash per one type of info", though. In any case it is a separate topic.