git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: What's cooking in git.git (Dec 2013, #02; Fri, 6)

From
Junio C Hamano <gitster@pobox.com>
Date
Dec 9, 2013, 17:48 UTC
Message-ID
<xmqq7gbd29vw.fsf@gitster.dls.corp.google.com>
In-Reply-To
<52A37D70.3090400@gmail.com>
Karsten Blees <karsten.blees@gmail.com> writes:
Show 5 quoted lines
>> * kb/fast-hashmap (2013-11-18) 14 commits
>>   (merged to 'next' on 2013-12-06 at f90be3d) 
>
> Damn, a day too late :-) I found these two glitches today...is a
> fixup patch OK or should I do a reroll (or separate patch on top)?

A separate patch on top would be the most appropriate. People have been looking at the change since mid November, and nobody noticed the problem; having a separate fix on top is a good way to document what the specific gotcha that can be easily missed is.

I think the patch you attached describes the issue well, possibly with a retitle (perhaps "hashmap.h: make sure map entries are tightly packed", or something.)

Thanks.
Show 44 quoted lines
> --- 8< ---
> Subject: [PATCH] fixup! add a hashtable implementation that supports O(1) removal
>
> Use 'unsigned int' for hash-codes everywhere.
>
> Extending 'struct hashmap_entry' with an int-sized member shouldn't waste
> memory on 64-bit systems. This is already documented in api-hashmap.txt,
> but needs '__attribute__((__packed__))' to work. Reduces e.g.
>
>  struct name_entry {
>      struct hashmap_entry ent;
>      int namelen;
>      char *name;
>  };
>
> from 32 to 24 bytes.
>
> Signed-off-by: Karsten Blees <blees@dcon.de>
> ---
>  hashmap.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hashmap.h b/hashmap.h
> index f5b3b61..b64567b 100644
> --- a/hashmap.h
> +++ b/hashmap.h
> @@ -15,7 +15,7 @@ extern unsigned int memihash(const void *buf, size_t len);
>  
>  /* data structures */
>  
> -struct hashmap_entry {
> +struct __attribute__((__packed__)) hashmap_entry {
>  	struct hashmap_entry *next;
>  	unsigned int hash;
>  };
> @@ -43,7 +43,7 @@ extern void hashmap_free(struct hashmap *map, int free_entries);
>  
>  /* hashmap_entry functions */
>  
> -static inline void hashmap_entry_init(void *entry, int hash)
> +static inline void hashmap_entry_init(void *entry, unsigned int hash)
>  {
>  	struct hashmap_entry *e = entry;
>  	e->hash = hash;
Previous: Junio C HamanoNext: Karsten Blees
Message 21 of 23 in “What's cooking in git.git (Dec 2013, #02; Fri, 6)”
  1. Junio C HamanoDec 6, 2013
  2. Felipe ContrerasDec 7, 2013
  3. Felipe ContrerasDec 7, 2013
  4. Junio C HamanoDec 9, 2013
  5. Thomas RastDec 7, 2013
  6. Jeff KingDec 9, 2013
  7. Junio C HamanoDec 9, 2013
  8. Matthieu MoyDec 7, 2013
  9. Karsten BleesDec 7, 2013
  10. Thomas RastDec 7, 2013
  11. Karsten BleesDec 7, 2013
  12. Thomas RastDec 8, 2013
  13. Karsten BleesDec 9, 2013
  14. Jonathan NiederDec 9, 2013
  15. Karsten BleesDec 9, 2013
  16. Jonathan NiederDec 9, 2013
  17. Karsten BleesDec 18, 2013
  18. Karsten BleesDec 18, 2013
  19. Karsten BleesDec 18, 2013
  20. Junio C HamanoDec 9, 2013
  21. Junio C HamanoDec 9, 2013
  22. hashmap.h: Use 'unsigned int' for hash-codes everywhereKarsten Blees, Dec 18, 2013
  23. Junio C HamanoDec 18, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.