1. 29 Jun, 2018 4 commits
  2. 16 May, 2018 1 commit
  3. 09 May, 2018 2 commits
  4. 08 May, 2017 1 commit
  5. 28 Jul, 2014 2 commits
    • Jeff King's avatar
      add object_as_type helper for casting objects · c4ad00f8
      Jeff King authored
      When we call lookup_commit, lookup_tree, etc, the logic goes
      something like:
      
        1. Look for an existing object struct. If we don't have
           one, allocate and return a new one.
      
        2. Double check that any object we have is the expected
           type (and complain and return NULL otherwise).
      
        3. Convert an object with type OBJ_NONE (from a prior
           call to lookup_unknown_object) to the expected type.
      
      We can encapsulate steps 2 and 3 in a helper function which
      checks whether we have the expected object type, converts
      OBJ_NONE as appropriate, and returns the object.
      
      Not only does this shorten the code, but it also provides
      one central location for converting OBJ_NONE objects into
      objects of other types. Future patches will use that to
      enforce type-specific invariants.
      
      Since this is a refactoring, we would want it to behave
      exactly as the current code. It takes a little reasoning to
      see that this is the case:
      
        - for lookup_{commit,tree,etc} functions, we are just
          pulling steps 2 and 3 into a function that does the same
          thing.
      
        - for the call in peel_object, we currently only do step 3
          (but we want to consolidate it with the others, as
          mentioned above). However, step 2 is a noop here, as the
          surrounding conditional makes sure we have OBJ_NONE
          (which we want to keep to avoid an extraneous call to
          sha1_object_info).
      
        - for the call in lookup_commit_reference_gently, we are
          currently doing step 2 but not step 3. However, step 3
          is a noop here. The object we got will have just come
          from deref_tag, which must have figured out the type for
          each object in order to know when to stop peeling.
          Therefore the type will never be OBJ_NONE.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      c4ad00f8
    • Jeff King's avatar
      move setting of object->type to alloc_* functions · fe24d396
      Jeff King authored
      The "struct object" type implements basic object
      polymorphism.  Individual instances are allocated as
      concrete types (or as a union type that can store any
      object), and a "struct object *" can be cast into its real
      type after examining its "type" enum.  This means it is
      dangerous to have a type field that does not match the
      allocation (e.g., setting the type field of a "struct blob"
      to "OBJ_COMMIT" would mean that a reader might read past the
      allocated memory).
      
      In most of the current code this is not a problem; the first
      thing we do after allocating an object is usually to set its
      type field by passing it to create_object. However, the
      virtual commits we create in merge-recursive.c do not ever
      get their type set. This does not seem to have caused
      problems in practice, though (presumably because we always
      pass around a "struct commit" pointer and never even look at
      the type).
      
      We can fix this oversight and also make it harder for future
      code to get it wrong by setting the type directly in the
      object allocation functions.
      
      This will also make it easier to fix problems with commit
      index allocation, as we know that any object allocated by
      alloc_commit_node will meet the invariant that an object
      with an OBJ_COMMIT type field will have a unique index
      number.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      fe24d396
  6. 14 Jul, 2014 2 commits
    • Jeff King's avatar
      add object_as_type helper for casting objects · 8ff226a9
      Jeff King authored
      When we call lookup_commit, lookup_tree, etc, the logic goes
      something like:
      
        1. Look for an existing object struct. If we don't have
           one, allocate and return a new one.
      
        2. Double check that any object we have is the expected
           type (and complain and return NULL otherwise).
      
        3. Convert an object with type OBJ_NONE (from a prior
           call to lookup_unknown_object) to the expected type.
      
      We can encapsulate steps 2 and 3 in a helper function which
      checks whether we have the expected object type, converts
      OBJ_NONE as appropriate, and returns the object.
      
      Not only does this shorten the code, but it also provides
      one central location for converting OBJ_NONE objects into
      objects of other types. Future patches will use that to
      enforce type-specific invariants.
      
      Since this is a refactoring, we would want it to behave
      exactly as the current code. It takes a little reasoning to
      see that this is the case:
      
        - for lookup_{commit,tree,etc} functions, we are just
          pulling steps 2 and 3 into a function that does the same
          thing.
      
        - for the call in peel_object, we currently only do step 3
          (but we want to consolidate it with the others, as
          mentioned above). However, step 2 is a noop here, as the
          surrounding conditional makes sure we have OBJ_NONE
          (which we want to keep to avoid an extraneous call to
          sha1_object_info).
      
        - for the call in lookup_commit_reference_gently, we are
          currently doing step 2 but not step 3. However, step 3
          is a noop here. The object we got will have just come
          from deref_tag, which must have figured out the type for
          each object in order to know when to stop peeling.
          Therefore the type will never be OBJ_NONE.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      8ff226a9
    • Jeff King's avatar
      move setting of object->type to alloc_* functions · d36f51c1
      Jeff King authored
      The "struct object" type implements basic object
      polymorphism.  Individual instances are allocated as
      concrete types (or as a union type that can store any
      object), and a "struct object *" can be cast into its real
      type after examining its "type" enum.  This means it is
      dangerous to have a type field that does not match the
      allocation (e.g., setting the type field of a "struct blob"
      to "OBJ_COMMIT" would mean that a reader might read past the
      allocated memory).
      
      In most of the current code this is not a problem; the first
      thing we do after allocating an object is usually to set its
      type field by passing it to create_object. However, the
      virtual commits we create in merge-recursive.c do not ever
      get their type set. This does not seem to have caused
      problems in practice, though (presumably because we always
      pass around a "struct commit" pointer and never even look at
      the type).
      
      We can fix this oversight and also make it harder for future
      code to get it wrong by setting the type directly in the
      object allocation functions.
      
      This will also make it easier to fix problems with commit
      index allocation, as we know that any object allocated by
      alloc_commit_node will meet the invariant that an object
      with an OBJ_COMMIT type field will have a unique index
      number.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
      d36f51c1
  7. 19 Jan, 2010 1 commit
  8. 17 Apr, 2007 1 commit
  9. 27 Feb, 2007 1 commit
    • Nicolas Pitre's avatar
      convert object type handling from a string to a number · 21666f1a
      Nicolas Pitre authored
      We currently have two parallel notation for dealing with object types
      in the code: a string and a numerical value.  One of them is obviously
      redundent, and the most used one requires more stack space and a bunch
      of strcmp() all over the place.
      
      This is an initial step for the removal of the version using a char array
      found in object reading code paths.  The patch is unfortunately large but
      there is no sane way to split it in smaller parts without breaking the
      system.
      Signed-off-by: 's avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
      21666f1a
  10. 20 Dec, 2006 1 commit
    • Junio C Hamano's avatar
      simplify inclusion of system header files. · 85023577
      Junio C Hamano authored
      This is a mechanical clean-up of the way *.c files include
      system header files.
      
       (1) sources under compat/, platform sha-1 implementations, and
           xdelta code are exempt from the following rules;
      
       (2) the first #include must be "git-compat-util.h" or one of
           our own header file that includes it first (e.g. config.h,
           builtin.h, pkt-line.h);
      
       (3) system headers that are included in "git-compat-util.h"
           need not be included in individual C source files.
      
       (4) "git-compat-util.h" does not have to include subsystem
           specific header files (e.g. expat.h).
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
      85023577
  11. 13 Jul, 2006 1 commit
  12. 20 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Add specialized object allocator · 855419f7
      Linus Torvalds authored
      This creates a simple specialized object allocator for basic
      objects.
      
      This avoids wasting space with malloc overhead (metadata and
      extra alignment), since the specialized allocator knows the
      alignment, and that objects, once allocated, are never freed.
      
      It also allows us to track some basic statistics about object
      allocations. For example, for the mozilla import, it shows
      object usage as follows:
      
           blobs:   627629 (14710 kB)
           trees:  1119035 (34969 kB)
         commits:   196423  (8440 kB)
            tags:     1336    (46 kB)
      
      and the simpler allocator shaves off about 2.5% off the memory
      footprint off a "git-rev-list --all --objects", and is a bit
      faster too.
      
      [ Side note: this concludes the series of "save memory in object storage".
        The thing is, there simply isn't much more to be saved on the objects.
      
        Doing "git-rev-list --all --objects" on the mozilla archive has a final
        total RSS of 131498 pages for me: that's about 513MB. Of that, the
        object overhead is now just 56MB, the rest is going somewhere else (put
        another way: the fact that this patch shaves off 2.5% of the total
        memory overhead, considering that objects are now not much more than 10%
        of the total shows how big the wasted space really was: this makes
        object allocations much more memory- and time-efficient).
      
        I haven't looked at where the rest is, but I suspect the bulk of it is
        just the pack-file loading. It may be that we should pack the tree
        objects separately from the blob objects: for git-rev-list --objects, we
        don't actually ever need to even look at the blobs, but since trees and
        blobs are interspersed in the pack-file, we end up not being dense in
        the tree accesses, so we end up looking at more pages than we strictly
        need to.
      
        So with a 535MB pack-file, it's entirely possible - even likely - that
        most of the remaining RSS is just the mmap of the pack-file itself. We
        don't need to map in _all_ of it, but we do end up mapping a fair
        amount. ]
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
      855419f7
  13. 18 Jun, 2006 1 commit
    • Linus Torvalds's avatar
      Shrink "struct object" a bit · 885a86ab
      Linus Torvalds authored
      This shrinks "struct object" by a small amount, by getting rid of the
      "struct type *" pointer and replacing it with a 3-bit bitfield instead.
      
      In addition, we merge the bitfields and the "flags" field, which
      incidentally should also remove a useless 4-byte padding from the object
      when in 64-bit mode.
      
      Now, our "struct object" is still too damn large, but it's now less
      obviously bloated, and of the remaining fields, only the "util" (which is
      not used by most things) is clearly something that should be eventually
      discarded.
      
      This shrinks the "git-rev-list --all" memory use by about 2.5% on the
      kernel archive (and, perhaps more importantly, on the larger mozilla
      archive). That may not sound like much, but I suspect it's more on a
      64-bit platform.
      
      There are other remaining inefficiencies (the parent lists, for example,
      probably have horrible malloc overhead), but this was pretty obvious.
      
      Most of the patch is just changing the comparison of the "type" pointer
      from one of the constant string pointers to the appropriate new TYPE_xxx
      small integer constant.
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
      885a86ab
  14. 04 Apr, 2006 1 commit
  15. 07 Jan, 2006 1 commit
    • Junio C Hamano's avatar
      [PATCH] Compilation: zero-length array declaration. · 8f1d2e6f
      Junio C Hamano authored
      ISO C99 (and GCC 3.x or later) lets you write a flexible array
      at the end of a structure, like this:
      
      	struct frotz {
      		int xyzzy;
      		char nitfol[]; /* more */
      	};
      
      GCC 2.95 and 2.96 let you to do this with "char nitfol[0]";
      unfortunately this is not allowed by ISO C90.
      
      This declares such construct like this:
      
      	struct frotz {
      		int xyzzy;
      		char nitfol[FLEX_ARRAY]; /* more */
      	};
      
      and git-compat-util.h defines FLEX_ARRAY to 0 for gcc 2.95 and
      empty for others.
      
      If you are using a C90 C compiler, you should be able
      to override this with CFLAGS=-DFLEX_ARRAY=1 from the
      command line of "make".
      Signed-off-by: 's avatarJunio C Hamano <junkio@cox.net>
      8f1d2e6f
  16. 08 Jun, 2005 1 commit
  17. 20 May, 2005 1 commit
  18. 06 May, 2005 1 commit
    • Nicolas Pitre's avatar
      [PATCH] don't load and decompress objects twice with parse_object() · bd2c39f5
      Nicolas Pitre authored
      It turns out that parse_object() is loading and decompressing given
      object to free it just before calling the specific object parsing
      function which does mmap and decompress the same object again. This
      patch introduces the ability to parse specific objects directly from a
      memory buffer.
      
      Without this patch, running git-fsck-cache on the kernel repositorytake:
      
      	real    0m13.006s
      	user    0m11.421s
      	sys     0m1.218s
      
      With this patch applied:
      
      	real    0m8.060s
      	user    0m7.071s
      	sys     0m0.710s
      
      The performance increase is significant, and this is kind of a
      prerequisite for sane delta object support with fsck.
      Signed-off-by: 's avatarNicolas Pitre <nico@cam.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      bd2c39f5
  19. 04 May, 2005 1 commit
  20. 28 Apr, 2005 1 commit
  21. 26 Apr, 2005 1 commit
  22. 24 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      fsck-cache: notice missing "blob" objects. · 4728b861
      Linus Torvalds authored
      We should _not_ mark a blob object "parsed" just because we
      looked it up: it gets marked that way only once we've actually
      seen it. Otherwise we can never notice a missing blob.
      4728b861
  23. 18 Apr, 2005 1 commit