Add struct strmap and associated utility functions

Here I introduce a new strmap type, which my new merge backed, merge-ort, uses heavily. (I also made significant use of it in my changes to diffcore-rename). This strmap type was based on Peff's proposal from a couple years ago[1], but has additions that I made as I used it. I also start the series off with a quick documentation improvement to hashmap.c to differentiate between hashmap_free() and hashmap_free_entries(), since I personally had difficulty understanding them and it affects how strmap_clear()/strmap_free() are written.

The biggest issue I know about currently concerns the convenience functions for a string->integer mapping. I wanted such a mapping that didn't need to allocate an extra int but instead works by just type-casting the void* pointer to an int instead. That all seems to work, but I needed a separate name for that type, and the problem is that I couldn't come up with a good one as you'll see in the last patch. Suggestions for better naming are very much welcome. As are, of course, suggestions for other API or implementation improvements.

[1]
https://lore.kernel.org/git/[email protected]/

Elijah Newren (5):
hashmap: add usage documentation explaining hashmap_free[_entries]()
strmap: new utility functions
strmap: add more utility functions
strmap: add strdup_strings option
strmap: add functions facilitating use as a string->int map

 Makefile  |   1 +
 hashmap.h |  27 +++++++++++-
 strmap.c  | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 strmap.h  | 123 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 275 insertions(+), 2 deletions(-)
 create mode 100644 strmap.c
 create mode 100644 strmap.h

base-commit: 675a4aaf3b226c0089108221b96559e0baae5de9
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-835%2Fnewren%2Fstrmap-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-835/newren/strmap-v1
Pull-Request: https://github.com/git/git/pull/835

gitgitgadget

From: Elijah Newren <[email protected]>

The existence of hashmap_free() and hashmap_free_entries() confused me, and the docs weren't clear enough. I had to consult other source code examples and the implementation. Add a brief note to clarify, especially since hashmap_clear*() variants may be added in the future.

---
 hashmap.h | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

index ef220de4c6..a2f4adc1b3 100644
@@ -236,13 +236,36 @@ void hashmap_init(struct hashmap *map,
 void hashmap_free_(struct hashmap *map, ssize_t offset);
 
 /*
- * Frees a hashmap structure and allocated memory, leaves entries undisturbed
+ * Frees a hashmap structure and allocated memory for the table, but does not
+ * free the entries nor anything they point to.
+ *
+ * Usage note:
+ *
+ * Many callers will need to iterate over all entries and free the data each
+ * entry points to; in such a case, they can free the entry itself while at it.
+ * Thus, you might see:
+ *    hashmap_for_each_entry(map, hashmap_iter, e, hashmap_entry_name) {
+ *      free(e->somefield);
+ *      free(e);
+ *    }
+ *    hashmap_free(map);
+ * instead of
+ *    hashmap_for_each_entry(map, hashmap_iter, e, hashmap_entry_name) {
+ *      free(e->somefield);
+ *    }
+ *    hashmap_free_entries(map, struct my_entry_struct, hashmap_entry_name);
+ * to avoid the implicit extra loop over the entries.  However, if there are
+ * no special fields in your entry that need to be freed beyond the entry
+ * itself, it is probably simpler to avoid the explicit loop and just call
+ * hashmap_free_entries().
  */
 #define hashmap_free(map) hashmap_free_(map, -1)
 
 /*
  * Frees @map and all entries.  @type is the struct type of the entry
- * where @member is the hashmap_entry struct used to associate with @map
+ * where @member is the hashmap_entry struct used to associate with @map.
+ *
+ * See usage note above hashmap_free().
  */
 #define hashmap_free_entries(map, type, member) \
 	hashmap_free_(map, offsetof(type, member));

gitgitgadget

Thanks, I think this is worth doing and the text looks clear and correct to me.

A minor nit, but a blank line between the code snippets and the text might make it a little more readable.

-Peff

From: Elijah Newren <[email protected]>

Add strmap as a new struct and associated utility functions, specifically for hashmaps that map strings to some value. The API is taken directly from Peff's proposal at
https://lore.kernel.org/git/[email protected]/

Peff only included the header, not the implementation, so it isn't clear what the structure was he was going to use for the hash entries. Instead of having my str_entry struct have three subfields (the hashmap_entry, the string, and the void* value), I made it only have two -- the hashmap_entry and a string_list_item, for two reasons:

1) a strmap is often the data structure we want where string_list has been used in the past. Using the same building block for individual entries in both makes it easier to adopt and reuse parts of the string_list API in strmap.

2) In some cases, after doing lots of other work, I want to be able to iterate over the items in my strmap in sorted order. hashmap obviously doesn't support that, but I wanted to be able to export the strmap to a string_list easily and then use its functions. (Note: I do not need the data structure to both be sorted and have efficient lookup at all times. If I did, I might use a B-tree instead, as suggested by brian in response to Peff in the thread noted above. In my case, most strmaps will never need sorting, but in one special case at the very end of a bunch of other work I want to iterate over the items in sorted order without doing any more lookups afterward.)

Also, I removed the STRMAP_INIT macro, since it cannot be used to correctly initialize a strmap; the underlying hashmap needs a call to hashmap_init() to allocate the hash table first.

---
 Makefile |  1 +
 strmap.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 strmap.h | 47 ++++++++++++++++++++++++++++++++
 3 files changed, 129 insertions(+)
 create mode 100644 strmap.c
 create mode 100644 strmap.h

index 65f8cfb236..0da15a9ee5 100644
@@ -988,6 +988,7 @@ LIB_OBJS += strbuf.o
 LIB_OBJS += strvec.o
 LIB_OBJS += streaming.o
 LIB_OBJS += string-list.o
+LIB_OBJS += strmap.o
 LIB_OBJS += sub-process.o
 LIB_OBJS += submodule-config.o
 LIB_OBJS += submodule.o

gitgitgadget

Uh oh. You are encouraging me in the belief that I can send half-baked ideas to the list and somebody will come along and implement them for me. ;)

I'd probably have done:

  struct strmap_entry {
	struct hashmap_entry ent;
	void *value;
	char key[FLEX_ALLOC];

};

That saves 8 bytes (plus malloc overhead)per item, plus avoids an extra pointer-chase for each item we consider when looking up.

I can see that there might be some value in being able to interchange the items for code that's expecting a string_list_item. But I have to wonder if the potential for confusion is worth it. I.e., should that code really be expecting a raw string pointer (possibly with a separate void pointer, or even better an actual typed pointer).

I'll keep an eye out as I read the rest of the series for code which uses this.

Hmm. Likewise, I'll keep an eye open for how this works in practice. I do suspect that a B-tree might be a better solution here, but implementing it is non-trivial, and most callers don't care about this property.

If the interim solution is to just dump it to a string_list and sort that, that's really not that bad, assuming it just happens once after we've added everything. I'm not sure there's that big a benefit to using string_list_item internally, since presumably that conversion needs to write a whole new array of string_list_items anyway.

Since access to the underlying hashmap happens through strmap functions, they could lazily initialize it. That's how oidmap works.

  if (!map || !map->map.table)

  struct strmap foo = { .free_values = 1 };
  ...
  strmap_put(&foo, "key", value);
  ...
  strmap_clear(&foo);

  if (!map->map.table) {
	strmap_init(map);
	entry = NULL;
  } else {
        entry = find_str_entry(map, str);

  FLEX_ALLOC_STR(entry, key, str);
  hashmap_entry_init(&entry->ent, strhash(str));
  entry->value = data;
  hashmap_add(&map->map, &entry->ent);

          return NULL;

          return NULL;

From: Elijah Newren <[email protected]>

This adds a number of additional convienence functions I want/need:
* strmap_empty()
* strmap_get_size()
* strmap_remove()
* strmap_for_each_entry()
* strmap_free()
* strmap_get_item()

I suspect the first four are self-explanatory.

strmap_free() differs from strmap_clear() in that the data structure is not reusable after it is called; strmap_clear() is not sufficient for the API because without strmap_free() we will leak memory.

strmap_get_item() is similar to strmap_get() except that instead of just returning the void* value that the string maps to, it returns the string_list_item that contains both the string and the void* value (or NULL if the string isn't in the map). This is helpful because it avoids multiple lookups, e.g. in some cases a caller would need to call:
* strmap_contains() to check that the map has an entry for the string
* strmap_get() to get the void* value
* <do some work to update the value>
* strmap_put() to update/overwrite the value
If the void* pointer returned really is a pointer, then the last step is unnecessary, but if the void* pointer is just cast to an integer then strmap_put() will be needed. In contrast, one can call strmap_get_item() and then:
* check if the string was in the map by whether the pointer is NULL
* access the value via item->util
* directly update item->util
meaning that we can replace two or three hash table lookups with one.

---
 strmap.c | 35 ++++++++++++++++++++++++++++++-----
 strmap.h | 43 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 73 insertions(+), 5 deletions(-)

index 1c9fdb3b1e..a4bfffcd8b 100644
@@ -27,7 +27,7 @@ void strmap_init(struct strmap *map)
 	hashmap_init(&map->map, cmp_str_entry, NULL, 0);
 }
 
-void strmap_clear(struct strmap *map, int free_util)
+void strmap_free(struct strmap *map, int free_util)
 {
 	struct hashmap_iter iter;
 	struct str_entry *e;

@@ -35,12 +35,19 @@ void strmap_clear(struct strmap *map, int free_util)
 	if (!map)
 		return;
 
-	hashmap_for_each_entry(&map->map, &iter, e, ent /* member name */) {
-		free(e->item.string);
-		if (free_util)
-			free(e->item.util);
+	if (free_util) {
+		hashmap_for_each_entry(&map->map, &iter, e, ent) {
+			free(e->item.string);
+			if (free_util)
+				free(e->item.util);
+		}
 	}
 	hashmap_free_entries(&map->map, struct str_entry, ent);
+}
+
+void strmap_clear(struct strmap *map, int free_util)
+{
+	strmap_free(map, free_util);
 	strmap_init(map);
 }
 

@@ -69,6 +76,13 @@ void *strmap_put(struct strmap *map, const char *str, void *data)
 	return old;
 }
 
+struct string_list_item *strmap_get_item(struct strmap *map,
+					 const char *str)
+{
+	struct str_entry *entry = find_str_entry(map, str);
+	return entry ? &entry->item : NULL;
+}
+
 void *strmap_get(struct strmap *map, const char *str)
 {
 	struct str_entry *entry = find_str_entry(map, str);

@@ -79,3 +93,14 @@ int strmap_contains(struct strmap *map, const char *str)
 {
 	return find_str_entry(map, str) != NULL;
 }
+
+void strmap_remove(struct strmap *map, const char *str, int free_util)
+{
+	struct str_entry entry, *ret;
+	hashmap_entry_init(&entry.ent, strhash(str));
+	entry.item.string = (char *)str;
+	ret = hashmap_remove_entry(&map->map, &entry, ent, NULL);
+	if (ret && free_util)
+		free(ret->item.util);
+	free(ret);
+}

gitgitgadget

Yup, all make sense. We might also want real iterators rather than strmap_for_each_entry(), which can be a bit more convenient given the lack of lambdas in C. But I'd be happy to wait until a caller arises.

Hmm, I missed in the previous function that strmap_clear() is actually leaving allocated memory. I think this is bad, because it's unlike most of our other data structure clear() functions.

We could work around it with the lazy-init stuff I mentioned in my last email (i.e., _don't_ strmap_init() at the end of strmap_clear(), and just let strmap_put() take care of initializing if somebody actually adds something again).

But IMHO this is a sign that we should be fixing hashmap() to work like that, too.

That makes sense. If you follow my suggestion to drop string_list_item, then it would be OK to return the whole str_entry. (I forgot to mention in the last patch, but perhaps strmap_entry would be a more distinctive name).

From: Elijah Newren <[email protected]>

Just as it is sometimes useful for string_list to duplicate and take ownership of memory management of the strings it contains, the same is sometimes true for strmaps as well. Add the same flag from string_list to strmap.

---
 strmap.c | 23 ++++++++++++++++-------
 strmap.h |  9 +++++----
 2 files changed, 21 insertions(+), 11 deletions(-)

index a4bfffcd8b..03eb6af45d 100644
@@ -22,9 +22,10 @@ static struct str_entry *find_str_entry(struct strmap *map,
 	return hashmap_get_entry(&map->map, &entry, ent, NULL);
 }
 
-void strmap_init(struct strmap *map)
+void strmap_init(struct strmap *map, int strdup_strings)
 {
 	hashmap_init(&map->map, cmp_str_entry, NULL, 0);
+	map->strdup_strings = strdup_strings;
 }
 
 void strmap_free(struct strmap *map, int free_util)

@@ -35,9 +36,10 @@ void strmap_free(struct strmap *map, int free_util)
 	if (!map)
 		return;
 
-	if (free_util) {
+	if (map->strdup_strings || free_util) {
 		hashmap_for_each_entry(&map->map, &iter, e, ent) {
-			free(e->item.string);
+			if (map->strdup_strings)
+				free(e->item.string);
 			if (free_util)
 				free(e->item.util);
 		}

@@ -48,12 +50,11 @@ void strmap_free(struct strmap *map, int free_util)
 void strmap_clear(struct strmap *map, int free_util)
 {
 	strmap_free(map, free_util);
-	strmap_init(map);
+	strmap_init(map, map->strdup_strings);
 }
 
 /*
- * Insert "str" into the map, pointing to "data". A copy of "str" is made, so
- * it does not need to persist after the this function is called.
+ * Insert "str" into the map, pointing to "data".
  *
  * If an entry for "str" already exists, its data pointer is overwritten, and
  * the original data pointer returned. Otherwise, returns NULL.

@@ -69,7 +70,13 @@ void *strmap_put(struct strmap *map, const char *str, void *data)
 	} else {
 		entry = xmalloc(sizeof(*entry));
 		hashmap_entry_init(&entry->ent, strhash(str));
-		entry->item.string = strdup(str);
+		/*
+		 * We won't modify entry->item.string so it really should be
+		 * const, but changing string_list_item to use a const char *
+		 * is a bit too big of a change at this point.
+		 */
+		entry->item.string =
+			map->strdup_strings ? xstrdup(str) : (char *)str;
 		entry->item.util = data;
 		hashmap_add(&map->map, &entry->ent);
 	}

@@ -100,6 +107,8 @@ void strmap_remove(struct strmap *map, const char *str, int free_util)
 	hashmap_entry_init(&entry.ent, strhash(str));
 	entry.item.string = (char *)str;
 	ret = hashmap_remove_entry(&map->map, &entry, ent, NULL);
+	if (map->strdup_strings)
+		free(ret->item.string);
 	if (ret && free_util)
 		free(ret->item.util);
 	free(ret);

index 45d0a4f714..28a98c5a4b 100644
@@ -6,6 +6,7 @@
 
 struct strmap {
 	struct hashmap map;
+	unsigned int strdup_strings:1;
 };
 
 struct str_entry {

@@ -14,9 +15,10 @@ struct str_entry {
 };
 
 /*
- * Initialize an empty strmap
+ * Initialize the members of the strmap, set `strdup_strings`
+ * member according to the value of the second parameter.
  */
-void strmap_init(struct strmap *map);
+void strmap_init(struct strmap *map, int strdup_strings);
 
 /*
  * Remove all entries from the map, releasing any allocated resources.

@@ -29,8 +31,7 @@ void strmap_free(struct strmap *map, int free_values);
 void strmap_clear(struct strmap *map, int free_values);
 
 /*
- * Insert "str" into the map, pointing to "data". A copy of "str" is made, so
- * it does not need to persist after the this function is called.
+ * Insert "str" into the map, pointing to "data".
  *
  * If an entry for "str" already exists, its data pointer is overwritten, and
  * the original data pointer returned. Otherwise, returns NULL.

gitgitgadget

This is actually one of the ugliest parts of string_list, IMHO, and I'd prefer if we can avoid duplicating it. Yes, sometimes we can manage to avoid an extra copy of a string. But the resulting ownership and lifetime questions are often very error-prone. In other data structures we've moved towards just having the structure own its data (e.g., strvec does so, and things like oidmap store their own oids). I've been happy with the simplicity of it.

It also works if you use a flex-array for the key storage in the strmap_entry. :)

-Peff

I can see how it's easier, but that worries me about the number of extra copies for my usecase. In order to minimize actual computation, I track an awful lot of auxiliary data in merge-ort so that I know when I can safely perform many different case-specific optimizations. Among other things, this means 15 strmaps. 1 of those stores a mapping from all paths that traverse_trees() walks over (file or directory) to metadata about the content on the three different sides. 9 of the remaining 14 simply share the strings in the main strmap, because I don't need extra copies of the paths in the repository. I could (and maybe should) extend that to 11 of the 14. Only 3 actually do need to store a copy of the paths (because they store data used beyond the end of an inner recursive merge or can be used to accelerate subsequent commits in a rebase or cherry-pick sequence).

So, in most my cases, I don't want to duplicate strings. I actually started my implementation using FLEX_ALLOC_STR(), as you suggested earlier in this thread, but tossed it because of this same desire to not duplicate strings but just share them between the strmaps.

Granted, I made that decision before I had a complete implementation, so I didn't measure the actual costs. It's possible that was a premature optimization.

I'd have to see the code, of course, but:

- keep in mind you're allocating 8 bytes for a pointer (plus 24 for the rest of the strmap entry). If you use a flex-array you get those 8 bytes back. Full paths do tend to be longer than that, so it's probably net worse than a pointer to an existing string. But how much worse, and does it matter?

- That sounds like a lot of maps. :) I guess you've looked at compacting some of them into a single map-to-struct?

I'm just really concerned that it poisons the data structure with complexity that many of the other callers will have to deal with. We've had several "oops, strdup_strings wasn't what I expected it to be" bugs with string-list (in both directions: leaks and use-after-free). It would be nice to have actual numbers and see if it's worth the cost.

-Peff

I'll investigate; it may take a while...

Oh, map-to-struct is the primary use. But compacting them won't work, because the reason for the additional maps is that they have different sets of keys (this set of paths meet a certain condition...). Only one map contains all the paths involved in the merge.

Also, several of those maps don't even store a value; and are really just a set implemented via strmap (thus meaning the only bit of data I need for some conditions is whether any given path meets it). It seems slightly ugly to have to call strmap_put(map, string, NULL) for those. I wonder if I should have another strset type much like your suggesting for strintmap. Hmm...

Also, one thing that inflates the number of strmaps I use is that several of those conditions are specific to a certain side of the merge, thus requiring two strmaps for each of those special conditions.

I'll go get some and find out what the impact is.

OK, I guess I'm not surprised that you would not have missed such an obvious optimization. :)

FWIW, khash does have a "set" mode where it avoids allocating the value array at all.

What's the easiest way to benchmark merge-ort? I suspect I could swap out hashmap for khash (messily) in an hour or less.

-Peff

Cool.

Note that I discovered another optimization that I'm working on implementing; when finished, it should cut down a little more on the time spent on inexact rename detection. That should have the side effect of having the time spent on strmaps stick out some more in the overall timings (as a percentage of overall time anyway). So, I'm focused on that before I do other benchmarking work (which is part of the reason I mentioned my strmap/hashmap benchmarking last week might take a while).

Anyway, on to your question:

=== If you just want to be able to run the ort merge algorithm ===

Clone [email protected]:newren/git and checkout the 'ort' branch and build it. It currently changes the default merge algorithm to 'ort' and even ignores '-s recursive' by remapping it to '-s ort' (because I wanted to see how regression tests fared with ort as a replacement for recrusive). It should pass the regression tests if you want to run those first. But note that if you want to compare 'ort' to 'recursive', then currently you need to have two different git builds, one of my branch and one with a different checkout of something else (e.g. 2.28.0 or 'master' or whatever).

=== Decide the granularity of your timing ===

I suspect you know more than me here, but maybe my pointers are useful anyway...

Decide if you want to measure overall program runtime, or dive into details. I used both a simple 'time' and the better 'hyperfine' for the former, and used both 'perf' and GIT_TRACE2_PERF for the latter. One nice thing about GIT_TRACE2_PERF was I wrote a simple program to aggregate the times per region and provide percentages, in a script at the toplevel named 'summarize-perf' that I can use to prefix commands. Thus, I could for example run from my linux clone:

    $ ../git/summarize-perf git fast-rebase --onto HEAD base hwmon-updates
and I'd get output that looks something like (note that this is a
subset of the real output):
    1.400 : 35 : label:inmemory_nonrecursive
       0.827 : 41 : ..label:renames
          0.019 : <unmeasured> ( 2.2%)
          0.803 : 37 : ....label:regular renames
          0.004 : 31 : ....label:directory renames
          0.001 : 31 : ....label:process renames
       0.513 : 41 : ..label:collect_merge_info
       0.048 : 35 : ..label:process_entries
    0.117 : 1 : label:checkout
    0.000 : 1 : label:record_unmerged
and where those fields are <time> : <count> : <region label>.

=== If you want to time the testcases I used heavily while developing ===

The rebase-testcase/redo-timings script (in the ort branch) has details on what I actually ran, though it has some paranoia around attempting to make my laptop run semi-quietly and try to avoid all the variance that I wished I could control a bit better. And it assumes you are running in a linux clone with a few branches set up a certain way. Let me explain those tests without using that script, as simply as I can:

The setup for the particular cases I was testing is as follows:
* Clone the linux kernel, and run the following:

  $ git branch hwmon-updates fd8bdb23b91876ac1e624337bb88dc1dcc21d67e
  $ git branch hwmon-just-one fd8bdb23b91876ac1e624337bb88dc1dcc21d67e~34
  $ git branch base 4703d9119972bf586d2cca76ec6438f819ffa30e
  $ git switch -c 5.4-renames v5.4
  $ git mv drivers pilots
  $ git commit -m "Rename drivers/ to pilots/"

And from there, there were three primary tests I was comparing:

* Rename testcase, 35 patches:

  $ git checkout 5.4-renames^0
  $ git fast-rebase --onto HEAD base hwmon-updates

* Rename testcase, just 1 patch:

  $ git switch 5.4-renames^0
  $ git fast-rebase --onto HEAD base hwmon-just-one

* No renames (or at least very few renames) testcase, 35 patches:

  $ git checkout v5.4^0
  $ git branch -f hwmon-updates
fd8bdb23b91876ac1e624337bb88dc1dcc21d67e # Need to reset
hwmon-updates, due to fast-rebase done above
  $ git fast-rebase --onto HEAD base hwmon-updates

(If you want to compare with 'recursive' from a different build of git, just replace 'fast-rebase' with 'rebase'. You can also use 'rebase' instead of 'fast-rebase' on the ort branch and it'll use the ort merge algorithm, but you get all the annoying working-tree-updates-while-rebasing rather than just having the working tree updated at the end of the rebase. You also get all the annoying forks of 'git checkout' and 'git commit' that sequencer is guilty of spawning. But it certainly supports a lot more options and can save state to allow resuming after conflicts, unlike 'fast-rebase'.)

Well, you might be assuming I used sane strmaps, with each strmap having a fixed type for the stored value. That's mostly true, but there were two counterexamples I can think of: "paths" (the biggest strmap) is a map of string -> {merged_info OR conflict_info}, because merged_info is a smaller subset of conflict_info and saves space for each path that can be trivially merged. Also, in diffcore-rename, "dir_rename" starts life as a map of string -> strmap, but later transitions to string -> string, because I'm evil and didn't set up a temporary strmap like I probably should have.

Also, the code is littered with FIXME comments, unnecessary #ifdefs, and is generally in need of lots of cleanup. Sorry.

From: Elijah Newren <[email protected]>

Although strmap could be used as a string->int map, one either had to allocate an int for every entry and then deallocate later, or one had to do a bunch of casting between (void*) and (intptr_t).

Add some special functions that do the casting. Also, rename put->set for such wrapper functions since 'put' implied there may be some deallocation needed if the string was already found in the map, which isn't the case when we're storing an int value directly in the void* slot instead of using the void* slot as a pointer to data.

A note on the name: strintmap looks and sounds pretty lame to me, but after trying to come up with something better and having no luck, I figured I'd just go with it for a while and then at some point some better and obvious name would strike me and I could replace it. Several months later, I still don't have a better name. Hopefully someone else has one.

---
 strmap.c | 11 +++++++++++
 strmap.h | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 43 insertions(+)

index 03eb6af45d..cbb99f4030 100644
@@ -113,3 +113,14 @@ void strmap_remove(struct strmap *map, const char *str, int free_util)
 		free(ret->item.util);
 	free(ret);
 }
+
+void strintmap_incr(struct strmap *map, const char *str, intptr_t amt)
+{
+	struct str_entry *entry = find_str_entry(map, str);
+	if (entry) {
+		intptr_t *whence = (intptr_t*)&entry->item.util;
+		*whence += amt;
+	}
+	else
+		strintmap_set(map, str, amt);
+}

index 28a98c5a4b..5d9dd3ef58 100644
@@ -88,4 +88,36 @@ static inline unsigned int strmap_get_size(struct strmap *map)
 		var = hashmap_iter_next_entry_offset(iter, \
 						OFFSETOF_VAR(var, ent)))
 
+/*
+ * Helper functions for using strmap as map of string -> int, using the void*
+ * field to store the int instead of allocating an int and having the void*
+ * member point to the allocated int.
+ */
+
+static inline int strintmap_get(struct strmap *map, const char *str,
+				int default_value)
+{
+	struct string_list_item *result = strmap_get_item(map, str);
+	if (!result)
+		return default_value;
+	return (intptr_t)result->util;
+}
+
+static inline void strintmap_set(struct strmap *map, const char *str, intptr_t v)
+{
+	strmap_put(map, str, (void *)v);
+}
+
+void strintmap_incr(struct strmap *map, const char *str, intptr_t amt);
+
+static inline void strintmap_clear(struct strmap *map)
+{
+	strmap_clear(map, 0);
+}
+
+static inline void strintmap_free(struct strmap *map)
+{
+	strmap_free(map, 0);
+}
+
 #endif /* STRMAP_H */

gitgitgadget

I think wrapping this kind of hackery is worth doing.

You'd be able to use put() as usual, wouldn't you? It never deallocates the util field, but just returns the old one. And the caller knows that it's really an int, and shouldn't be deallocated.

strnummap? That's pretty bad, too.

Since the functions all take a raw strmap, you _could_ just do "strmap_getint()", etc. But I think you could actually get some additional safety by defining a wrapper type:

  struct strintmap {
          struct strmap strmap;
  };

It's a bit annoying because you a bunch of pass-through boilerplate for stuff like:

  static inline int strintmap_empty(struct strintmap *map)
  {
          return strmap_empty(&map->map);
  }

but it would prevent mistakes like:

  strintmap_incr(&map, "foo", 10);
  strmap_clear(&map, 1);

which would try to free (void *)10. I'm not sure if that's worth it or not. You'd almost have to be trying to fail to pass "1" for free_util there. But I've seen stranger things. :)

-Peff

You can use put() as normal, if you don't mind the need to explicitly throw in a typecast when you use it. In fact, strintmap_set() does no more than typecasting the int to void* and otherwise calling strmap_put().

I initially called that strintmap_put(), but got confused once or twice and looked up the function definition to make sure there wasn't some deallocation I needed to handle. After that, I decided to just rename to _set() because I thought it'd reduce the chance of myself or others wondering about that in the future.

I like this idea and the extra safety it provides. Most of strintmap is static inline functions anyway, adding a few more wouldn't hurt.

Yeah, I think hiding the type-casting is worth it alone. I was just confused by your remark.

Yeah, I'd agree that is a much better name. Since there's an "incr", having a specific "set" makes it clear that we're overwriting.

OK. Then I guess we can't cheat our way out of picking a name with strmap_getint(). :)

-Peff

I like the direction overall (unsurprisingly), but left a bunch of comments. I do think if we're going to do this that it may be worth cleaning up hashmap a bit first, especially around its clear/free semantics, and its ability to lazy-allocate the table.

I'm happy to work on that, but don't want to step on your toes.

I also wonder if you looked at the khash stuff at all. Especially for storing integers, it makes things much more natural. You'd do something like:

  /* you might even be able to just write !strcmp in the macro below */
  static inline int streq(const char *a, const char *b)
  {
          return !strcmp(a, b);
  }

  KHASH_INIT(strint_map, char *, int, 1, strhash, streq);

and then you'd probably want a "put" wrapper that makes a copy of the string. khash has its own charming awkwardness, but I'm just curious if you looked at it and found it more awkward than hashmap.c, or if you just didn't look at it.

-Peff

I have patches which introduce hashmap_clear() and hashmap_clear_entries() to hashmap.[ch], which allowed me to simplify strmap_clear(); instead of needing to call both hashmap_free[_entries]() && strmap_init(), I could just call hashmap_clear[_entries](). Doing that surprised me with a significant performance impact (in a good direction), at which point I started adding mem-pool integration into hashmap for storing the entries that hashmap.c allocates and got further good speedups.

I thought those were better explained when I got to the performance stuff, so I had held off on those patches. I could pull them out and submit them first.

However, there's an important difference here between what I've done and what you've suggested for hashmap: my method did not deallocate hashmap->table in hashmap_clear() and then use lazy initialization. In fact, I think not deallocating the table was part of the charm -- the table had already naturally grown to the right size, and because the repository has approximately the same number of paths in various commits, this provided me a way of getting a table preallocated to a reasonable size for all merges after the first (and there are multiple merges either when recursiveness is needed due to multiple merge bases, OR when rebasing or cherry-picking a sequence of commits). This prevented, as hashmap.h puts it, "expensive resizing".

So, once again, my performance ideas might be clashing with some of your desires for the API. Any clever ideas for resolving that?

Also, since you want to see hashmap cleanup first, should I submit just the hashmap_clear[_entries()] stuff, or should I also submit the API additions to allow mem-pool integration in hashmap (it's pretty small and self-contained, but it'll be a while before I submit the patches that use it...)?

I did look at it, but only briefly. I had a further investigation on my TODO list for months, along with several other improvement ideas. But it seemed like my TODO list was really long, and my new merge backend hasn't benefited anyone yet. At some point, I decided to punt on it and other ideas and start cleaning up my code and submitting. I believe merge-ort is more accurate than merge-recursive (it fixes several test_expect_failures) and is a lot faster as well for the cases I'm looking at. So, for now, I've pulled it off my radar.

But I'd be really happy if someone else wanted to jump in and try switching out hashmap for khash in the strmap API and see if it helps merge-ort performance. :-)

Nevermind, I mis-remembered. The mempool integration was added specifically to strmap, not to hashmap, because strmap_put() does the allocation of the str_entry. So I'll just pull out the hashmap_clear[_entries]() stuff and send it up.

If the magic is in pre-sizing the hash, then it seems like the callers ought to be feeding the size hint. That does make a little more work for them, but I think there's real value in having consistent semantics for "clear" across our data structures.

However, one cheat would be to free the memory but retain the size hint after a clear. And then if we lazy-init, grow immediately to the hint size. That's more expensive than a true reuse, because we do reallocate the memory. But it avoids the repeated re-allocation during growth.

It may also be a sign that we should be growing the hash more aggressively in the first place. Of course all of this is predicated having some benchmarks. It would be useful to know which part actually provided the speedup.

-Peff

I thought about adding a size hint from the callers, but the thing is I don't know how to get a good one short of running a merge and querying how big things were sized in that merge. (In some common cases I can get an upper bound, but I can't get it in all cases and that upper bound might be a couple orders of magnitude too big.) Thus, it's really a case where I just punt on pre-sizing for the first merge, and use the size from the previous merge for subsequent ones. If you have a non-recursive merge or are cherry-picking only a single commit, then no sizing hint is used.

Your thoughts here are great; I also had another one this past week -- I could introduce a hashmap_partial_clear() (in addition to hashmap_clear()) for the special usecase I have of leaving the table allocated and pre-sized. It'd prevent people from accidentally using it and forgetting to free stuff, while still allowing me to take advantage. But, as you say, more benchmarks would be useful to find which parts provided the speedup before taking any of these steps.

Yeah, having a separate function to explicitly do "remove all elements but keep the table allocated" would be fine with me. My big desire is that clear() should do the safe, non-leaking thing by default.

-Peff

Here I introduce a new strmap type, which my new merge backed, merge-ort, uses heavily. (I also made significant use of it in my changes to diffcore-rename). This strmap type was based on Peff's proposal from a couple years ago[1], but has additions that I made as I used it. I also start the series off with some changes to hashmap, based on Peff's feedback on v1.

Changes since v1:

* Rebased on newer origin/master (to resolve a conflict in Makefile)
* First fixed hashmap to allow it to continue to be used after hashmap_free() is called, as requested by Peff.
* Renamed my hashmap_clear() to hashmap_partial_clear() to avoid mis-use and make it clear it doesn't free everything.
* Distanced the API from string-list, as per feedback from Peff. In particular, removed the use of string_list_item, and made strdup_strings the default -- strmap_init() does not accept a strdup_strings parameter it just defaults to on; one has to call strmap_ocd_init() instead if one wants to control the memory closely.
* Added strintmap and strset types, for string->int mappings, and cases where we just want a set of keys rather than having each key map to some value.
* Also included a patch enabling strmaps to make use of mem_pools (also only accessible via the strmap_ocd_init() constructor ); I previously thought this only made sense to include after the relevant point in merge-ort, but I figured since it slightly affects the API (it was part of what led me to the strmap_ocd_init() name), I decided to include it for now.
* The hashmap_partial_clear() and strmap_partial_clear() additions in patches 4 and 7 could also potentially be deferred much like mem_pool additions, but again, I decided to include them because they give a better picture of the overall usage I have and usecases I'm trying to design the API for.

Things Peff mentioned that are NOT included in this v2:

* Peff brought up the idea of having a free_values member instead of having a free_util parameter to strmap_clear(). I think that would just mean moving the parameter from strmap_clear() to strmap_init().
* Peff wanted the strmap_entry type to have a char key[FLEX_ALLOC] instead of having a (const) char *key.

Explanations/excuses for the above:

* For the free_values member, it sounded like Peff didn't have a strong opinion. I don't either, so I'm happy to switch it if someone feels strongly. But since it sounded like a thinking-out-loud comment and I couldn't see an advantage one way or the other, I left things as-is.
* For the FLEX_ALLOC implementation, Peff did have a clear strong preference. I put a day or so of time into trying to get an alternate implementation working (and I at least ripped out the string_list_item sub-type, made the key be const, and fixed the ugly casts), but didn't quite get the code to a working state. (Not only does it change the memory management quite a bit in ways that I need to run under valgrind both with and without mem_pools, but there's an extra wrinkle as well:
merge-ort differs from merge-recursive in that all filepaths come from a single tree traversal instead of several different ones, which means that I had the ability to compare path strings for equality via pointer comparisons instead of using strcmp. Copying strings for each of the different strmaps breaks that.) If the changes I've made aren't sufficient and folks still want to see the performance of a FLEX_ALLOC implementation, it's probably possible to get it working, just surprisingly non-trivial. For now, I at least wanted to get feedback on my other changes, and probe for whether folks do want me to put another day or two into this.

[1]
https://lore.kernel.org/git/[email protected]/

Elijah Newren (10):
hashmap: add usage documentation explaining hashmap_free[_entries]()
hashmap: adjust spacing to fix argument alignment
hashmap: allow re-use after hashmap_free()
hashmap: introduce a new hashmap_partial_clear()
strmap: new utility functions
strmap: add more utility functions
strmap: enable faster clearing and reusing of strmaps
strmap: add functions facilitating use as a string->int map
strmap: add a strset sub-type
strmap: enable allocations to come from a mem_pool

 Makefile  |   1 +
 hashmap.c |  72 +++++++++++-----
 hashmap.h |  44 +++++++++-
 strmap.c  | 152 +++++++++++++++++++++++++++++++++
 strmap.h  | 250 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 494 insertions(+), 25 deletions(-)
 create mode 100644 strmap.c
 create mode 100644 strmap.h

base-commit: d4a392452e292ff924e79ec8458611c0f679d6d4
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-835%2Fnewren%2Fstrmap-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-835/newren/strmap-v2
Pull-Request: https://github.com/git/git/pull/835

Range-diff vs v1:

1: b295e9393a ! 1: af6b6fcb46 hashmap: add usage documentation explaining hashmap_free[_entries]()
@@ Commit message
hashmap: add usage documentation explaining hashmap_free[_entries]()

The existence of hashmap_free() and hashmap_free_entries() confused me,
- and the docs weren't clear enough. I had to consult other source code
- examples and the implementation. Add a brief note to clarify,
- especially since hashmap_clear*() variants may be added in the future.
+ and the docs weren't clear enough. We are dealing with a map table,
+ entries in that table, and possibly also things each of those entries
+ point to. I had to consult other source code examples and the
+ implementation. Add a brief note to clarify the differences. This will
+ become even more important once we introduce a new
+ hashmap_partial_clear() function which will add the question of whether
+ the table itself has been freed.

@@ hashmap.h: void hashmap_init(struct hashmap *map,
+ * Many callers will need to iterate over all entries and free the data each
+ * entry points to; in such a case, they can free the entry itself while at it.
+ * Thus, you might see:
++ *
+ * hashmap_for_each_entry(map, hashmap_iter, e, hashmap_entry_name) {
+ * free(e->somefield);
+ * free(e);
+ * }
+ * hashmap_free(map);
++ *
+ * instead of
++ *
+ * hashmap_for_each_entry(map, hashmap_iter, e, hashmap_entry_name) {
+ * free(e->somefield);
+ * }
+ * hashmap_free_entries(map, struct my_entry_struct, hashmap_entry_name);
++ *
+ * to avoid the implicit extra loop over the entries. However, if there are
+ * no special fields in your entry that need to be freed beyond the entry
+ * itself, it is probably simpler to avoid the explicit loop and just call

  -:  ---------- >  2:  75f17619e9 hashmap: adjust spacing to fix argument alignment
  -:  ---------- >  3:  a686d0758a hashmap: allow re-use after hashmap_free()
  -:  ---------- >  4:  061ab45a9b hashmap: introduce a new hashmap_partial_clear()
  2:  a86fd5fdcc !  5:  5c7507f55b strmap: new utility functions
     @@ Commit message
          taken directly from Peff's proposal at
          https://lore.kernel.org/git/[email protected]/
      
     -    Peff only included the header, not the implementation, so it isn't clear what
     -    the structure was he was going to use for the hash entries.  Instead of having
     -    my str_entry struct have three subfields (the hashmap_entry, the string, and
     -    the void* value), I made it only have two -- the hashmap_entry and a
     -    string_list_item, for two reasons:
     +    A couple of items of note:
      
     -      1) a strmap is often the data structure we want where string_list has
     -         been used in the past.  Using the same building block for
     -         individual entries in both makes it easier to adopt and reuse
     -         parts of the string_list API in strmap.
     +      * Similar to string-list, I have a strdup_strings setting.  However,
     +        unlike string-list, strmap_init() does not take a parameter for this
     +        setting and instead automatically sets it to 1; callers who want to
     +        control this detail need to instead call strmap_ocd_init().
      
     -      2) In some cases, after doing lots of other work, I want to be able
     -         to iterate over the items in my strmap in sorted order.  hashmap
     -         obviously doesn't support that, but I wanted to be able to export
     -         the strmap to a string_list easily and then use its functions.
     -         (Note: I do not need the data structure to both be sorted and have
     -         efficient lookup at all times.  If I did, I might use a B-tree
     -         instead, as suggested by brian in response to Peff in the thread
     -         noted above.  In my case, most strmaps will never need sorting, but
     -         in one special case at the very end of a bunch of other work I want
     -         to iterate over the items in sorted order without doing any more
     -         lookups afterward.)
     -
     -    Also, I removed the STRMAP_INIT macro, since it cannot be used to
     -    correctly initialize a strmap; the underlying hashmap needs a call to
     -    hashmap_init() to allocate the hash table first.
     +      * I do not have a STRMAP_INIT macro.  I could possibly add one, but
     +          #define STRMAP_INIT { { NULL, cmp_str_entry, NULL, 0, 0, 0, 0, 0 }, 1 }
     +        feels a bit unwieldy and possibly error-prone in terms of future
     +        expansion of the hashmap struct.  The fact that cmp_str_entry needs to
     +        be in there prevents us from passing all zeros for the hashmap, and makes
     +        me worry that STRMAP_INIT would just be more trouble than it is worth.
      
          Signed-off-by: Elijah Newren <[email protected]>
      
       ## Makefile ##
     -@@ Makefile: LIB_OBJS += strbuf.o
     - LIB_OBJS += strvec.o
     +@@ Makefile: LIB_OBJS += stable-qsort.o
     + LIB_OBJS += strbuf.o
       LIB_OBJS += streaming.o
       LIB_OBJS += string-list.o
      +LIB_OBJS += strmap.o
     + LIB_OBJS += strvec.o
       LIB_OBJS += sub-process.o
       LIB_OBJS += submodule-config.o
     - LIB_OBJS += submodule.o
      
       ## strmap.c (new) ##
      @@
      +#include "git-compat-util.h"
      +#include "strmap.h"
      +
     -+static int cmp_str_entry(const void *hashmap_cmp_fn_data,
     -+			 const struct hashmap_entry *entry1,
     -+			 const struct hashmap_entry *entry2,
     -+			 const void *keydata)
     ++static int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
     ++			    const struct hashmap_entry *entry1,
     ++			    const struct hashmap_entry *entry2,
     ++			    const void *keydata)
      +{
     -+	const struct str_entry *e1, *e2;
     ++	const struct strmap_entry *e1, *e2;
      +
     -+	e1 = container_of(entry1, const struct str_entry, ent);
     -+	e2 = container_of(entry2, const struct str_entry, ent);
     -+	return strcmp(e1->item.string, e2->item.string);
     ++	e1 = container_of(entry1, const struct strmap_entry, ent);
     ++	e2 = container_of(entry2, const struct strmap_entry, ent);
     ++	return strcmp(e1->key, e2->key);
      +}
      +
     -+static struct str_entry *find_str_entry(struct strmap *map,
     -+					const char *str)
     ++static struct strmap_entry *find_strmap_entry(struct strmap *map,
     ++					      const char *str)
      +{
     -+	struct str_entry entry;
     ++	struct strmap_entry entry;
      +	hashmap_entry_init(&entry.ent, strhash(str));
     -+	entry.item.string = (char *)str;
     ++	entry.key = str;
      +	return hashmap_get_entry(&map->map, &entry, ent, NULL);
      +}
      +
      +void strmap_init(struct strmap *map)
      +{
     -+	hashmap_init(&map->map, cmp_str_entry, NULL, 0);
     ++	strmap_ocd_init(map, 1);
      +}
      +
     -+void strmap_clear(struct strmap *map, int free_util)
     ++void strmap_ocd_init(struct strmap *map,
     ++		     int strdup_strings)
     ++{
     ++	hashmap_init(&map->map, cmp_strmap_entry, NULL, 0);
     ++	map->strdup_strings = strdup_strings;
     ++}
     ++
     ++static void strmap_free_entries_(struct strmap *map, int free_util)
      +{
      +	struct hashmap_iter iter;
     -+	struct str_entry *e;
     ++	struct strmap_entry *e;
      +
      +	if (!map)
      +		return;
      +
     -+	hashmap_for_each_entry(&map->map, &iter, e, ent /* member name */) {
     -+		free(e->item.string);
     ++	/*
     ++	 * We need to iterate over the hashmap entries and free
     ++	 * e->key and e->value ourselves; hashmap has no API to
     ++	 * take care of that for us.  Since we're already iterating over
     ++	 * the hashmap, though, might as well free e too and avoid the need
     ++	 * to make some call into the hashmap API to do that.
     ++	 */
     ++	hashmap_for_each_entry(&map->map, &iter, e, ent) {
      +		if (free_util)
     -+			free(e->item.util);
     ++			free(e->value);
     ++		if (map->strdup_strings)
     ++			free((char*)e->key);
     ++		free(e);
      +	}
     -+	hashmap_free_entries(&map->map, struct str_entry, ent);
     -+	strmap_init(map);
      +}
      +
     -+/*
     -+ * Insert "str" into the map, pointing to "data". A copy of "str" is made, so
     -+ * it does not need to persist after the this function is called.
     -+ *
     -+ * If an entry for "str" already exists, its data pointer is overwritten, and
     -+ * the original data pointer returned. Otherwise, returns NULL.
     -+ */
     ++void strmap_clear(struct strmap *map, int free_util)
     ++{
     ++	strmap_free_entries_(map, free_util);
     ++	hashmap_free(&map->map);
     ++}
     ++
      +void *strmap_put(struct strmap *map, const char *str, void *data)
      +{
     -+	struct str_entry *entry = find_str_entry(map, str);
     ++	struct strmap_entry *entry = find_strmap_entry(map, str);
      +	void *old = NULL;
      +
      +	if (entry) {
     -+		old = entry->item.util;
     -+		entry->item.util = data;
     ++		old = entry->value;
     ++		entry->value = data;
      +	} else {
     ++		/*
     ++		 * We won't modify entry->key so it really should be const.
     ++		 */
     ++		const char *key = str;
     ++
      +		entry = xmalloc(sizeof(*entry));
      +		hashmap_entry_init(&entry->ent, strhash(str));
     -+		entry->item.string = strdup(str);
     -+		entry->item.util = data;
     ++
     ++		if (map->strdup_strings)
     ++			key = xstrdup(str);
     ++		entry->key = key;
     ++		entry->value = data;
      +		hashmap_add(&map->map, &entry->ent);
      +	}
      +	return old;
     @@ strmap.c (new)
      +
      +void *strmap_get(struct strmap *map, const char *str)
      +{
     -+	struct str_entry *entry = find_str_entry(map, str);
     -+	return entry ? entry->item.util : NULL;
     ++	struct strmap_entry *entry = find_strmap_entry(map, str);
     ++	return entry ? entry->value : NULL;
      +}
      +
      +int strmap_contains(struct strmap *map, const char *str)
      +{
     -+	return find_str_entry(map, str) != NULL;
     ++	return find_strmap_entry(map, str) != NULL;
      +}
      
       ## strmap.h (new) ##
     @@ strmap.h (new)
      +#define STRMAP_H
      +
      +#include "hashmap.h"
     -+#include "string-list.h"
      +
      +struct strmap {
      +	struct hashmap map;
     ++	unsigned int strdup_strings:1;
      +};
      +
     -+struct str_entry {
     ++struct strmap_entry {
      +	struct hashmap_entry ent;
     -+	struct string_list_item item;
     ++	const char *key;
     ++	void *value;
      +};
      +
      +/*
     -+ * Initialize an empty strmap
     ++ * Initialize the members of the strmap.  Any keys added to the strmap will
     ++ * be strdup'ed with their memory managed by the strmap.
      + */
      +void strmap_init(struct strmap *map);
      +
      +/*
     ++ * Same as strmap_init, but for those who want to control the memory management
     ++ * carefully instead of using the default of strdup_strings=1.
     ++ * (OCD = Obsessive Compulsive Disorder, a joke that those who use this function
     ++ * are obsessing over minor details.)
     ++ */
     ++void strmap_ocd_init(struct strmap *map,
     ++		     int strdup_strings);
     ++
     ++/*
      + * Remove all entries from the map, releasing any allocated resources.
      + */
      +void strmap_clear(struct strmap *map, int free_values);
      +
      +/*
     -+ * Insert "str" into the map, pointing to "data". A copy of "str" is made, so
     -+ * it does not need to persist after the this function is called.
     ++ * Insert "str" into the map, pointing to "data".
      + *
      + * If an entry for "str" already exists, its data pointer is overwritten, and
      + * the original data pointer returned. Otherwise, returns NULL.
  3:  5bda171d0c !  6:  61b5bf1110 strmap: add more utility functions
     @@ Commit message
            * strmap_get_size()
            * strmap_remove()
            * strmap_for_each_entry()
     -      * strmap_free()
     -      * strmap_get_item()
     +      * strmap_get_entry()
      
          I suspect the first four are self-explanatory.
      
     -    strmap_free() differs from strmap_clear() in that the data structure is
     -    not reusable after it is called; strmap_clear() is not sufficient for
     -    the API because without strmap_free() we will leak memory.
     -
     -    strmap_get_item() is similar to strmap_get() except that instead of just
     +    strmap_get_entry() is similar to strmap_get() except that instead of just
          returning the void* value that the string maps to, it returns the
     -    string_list_item that contains both the string and the void* value (or
     +    strmap_entry that contains both the string and the void* value (or
          NULL if the string isn't in the map).  This is helpful because it avoids
          multiple lookups, e.g. in some cases a caller would need to call:
            * strmap_contains() to check that the map has an entry for the string
     @@ Commit message
            * strmap_put() to update/overwrite the value
          If the void* pointer returned really is a pointer, then the last step is
          unnecessary, but if the void* pointer is just cast to an integer then
     -    strmap_put() will be needed.  In contrast, one can call strmap_get_item()
     +    strmap_put() will be needed.  In contrast, one can call strmap_get_entry()
          and then:
            * check if the string was in the map by whether the pointer is NULL
     -      * access the value via item->util
     -      * directly update item->util
     +      * access the value via entry->value
     +      * directly update entry->value
          meaning that we can replace two or three hash table lookups with one.
      
          Signed-off-by: Elijah Newren <[email protected]>
      
       ## strmap.c ##
     -@@ strmap.c: void strmap_init(struct strmap *map)
     - 	hashmap_init(&map->map, cmp_str_entry, NULL, 0);
     - }
     - 
     --void strmap_clear(struct strmap *map, int free_util)
     -+void strmap_free(struct strmap *map, int free_util)
     - {
     - 	struct hashmap_iter iter;
     - 	struct str_entry *e;
     -@@ strmap.c: void strmap_clear(struct strmap *map, int free_util)
     - 	if (!map)
     - 		return;
     - 
     --	hashmap_for_each_entry(&map->map, &iter, e, ent /* member name */) {
     --		free(e->item.string);
     --		if (free_util)
     --			free(e->item.util);
     -+	if (free_util) {
     -+		hashmap_for_each_entry(&map->map, &iter, e, ent) {
     -+			free(e->item.string);
     -+			if (free_util)
     -+				free(e->item.util);
     -+		}
     - 	}
     - 	hashmap_free_entries(&map->map, struct str_entry, ent);
     -+}
     -+
     -+void strmap_clear(struct strmap *map, int free_util)
     -+{
     -+	strmap_free(map, free_util);
     - 	strmap_init(map);
     - }
     - 
      @@ strmap.c: void *strmap_put(struct strmap *map, const char *str, void *data)
       	return old;
       }
       
     -+struct string_list_item *strmap_get_item(struct strmap *map,
     -+					 const char *str)
     ++struct strmap_entry *strmap_get_entry(struct strmap *map, const char *str)
      +{
     -+	struct str_entry *entry = find_str_entry(map, str);
     -+	return entry ? &entry->item : NULL;
     ++	return find_strmap_entry(map, str);
      +}
      +
       void *strmap_get(struct strmap *map, const char *str)
       {
     - 	struct str_entry *entry = find_str_entry(map, str);
     + 	struct strmap_entry *entry = find_strmap_entry(map, str);
      @@ strmap.c: int strmap_contains(struct strmap *map, const char *str)
       {
     - 	return find_str_entry(map, str) != NULL;
     + 	return find_strmap_entry(map, str) != NULL;
       }
      +
      +void strmap_remove(struct strmap *map, const char *str, int free_util)
      +{
     -+	struct str_entry entry, *ret;
     ++	struct strmap_entry entry, *ret;
      +	hashmap_entry_init(&entry.ent, strhash(str));
     -+	entry.item.string = (char *)str;
     ++	entry.key = str;
      +	ret = hashmap_remove_entry(&map->map, &entry, ent, NULL);
     -+	if (ret && free_util)
     -+		free(ret->item.util);
     ++	if (!ret)
     ++		return;
     ++	if (free_util)
     ++		free(ret->value);
     ++	if (map->strdup_strings)
     ++		free((char*)ret->key);
      +	free(ret);
      +}
      
       ## strmap.h ##
     -@@ strmap.h: void strmap_init(struct strmap *map);
     - /*
     -  * Remove all entries from the map, releasing any allocated resources.
     -  */
     -+void strmap_free(struct strmap *map, int free_values);
     -+
     -+/*
     -+ * Same as calling strmap_free() followed by strmap_init().
     -+ */
     - void strmap_clear(struct strmap *map, int free_values);
     - 
     - /*
      @@ strmap.h: void strmap_clear(struct strmap *map, int free_values);
        */
       void *strmap_put(struct strmap *map, const char *str, void *data);
       
      +/*
     -+ * Return the string_list_item mapped by "str", or NULL if there is not such
     ++ * Return the strmap_entry mapped by "str", or NULL if there is not such
      + * an item in map.
      + */
     -+struct string_list_item *strmap_get_item(struct strmap *map, const char *str);
     ++struct strmap_entry *strmap_get_entry(struct strmap *map, const char *str);
      +
       /*
        * Return the data pointer mapped by "str", or NULL if the entry does not
     @@ strmap.h: void *strmap_get(struct strmap *map, const char *str);
      +}
      +
      +/*
     -+ * iterate through @map using @iter, @var is a pointer to a type str_entry
     ++ * iterate through @map using @iter, @var is a pointer to a type strmap_entry
      + */
      +#define strmap_for_each_entry(mystrmap, iter, var)	\
      +	for (var = hashmap_iter_first_entry_offset(&(mystrmap)->map, iter, \
      +						   OFFSETOF_VAR(var, ent)); \
      +		var; \
      +		var = hashmap_iter_next_entry_offset(iter, \
     -+						OFFSETOF_VAR(var, ent)))
     ++						     OFFSETOF_VAR(var, ent)))
      +
       #endif /* STRMAP_H */
  -:  ---------- >  7:  2ebce0c5d8 strmap: enable faster clearing and reusing of strmaps
  5:  418975b460 !  8:  cc8d702f98 strmap: add functions facilitating use as a string->int map
     @@ Commit message
          isn't the case when we're storing an int value directly in the void*
          slot instead of using the void* slot as a pointer to data.
      
     -    A note on the name: strintmap looks and sounds pretty lame to me, but
     -    after trying to come up with something better and having no luck, I
     -    figured I'd just go with it for a while and then at some point some
     -    better and obvious name would strike me and I could replace it.  Several
     -    months later, I still don't have a better name.  Hopefully someone else
     -    has one.
     +    A note on the name: if anyone has a better name suggestion than
     +    strintmap, I'm happy to take it.  It seems slightly unwieldy, but I have
     +    not been able to come up with a better name.
      
          Signed-off-by: Elijah Newren <[email protected]>
      
       ## strmap.c ##
      @@ strmap.c: void strmap_remove(struct strmap *map, const char *str, int free_util)
     - 		free(ret->item.util);
     + 		free((char*)ret->key);
       	free(ret);
       }
      +
     -+void strintmap_incr(struct strmap *map, const char *str, intptr_t amt)
     ++void strintmap_incr(struct strintmap *map, const char *str, intptr_t amt)
      +{
     -+	struct str_entry *entry = find_str_entry(map, str);
     ++	struct strmap_entry *entry = find_strmap_entry(&map->map, str);
      +	if (entry) {
     -+		intptr_t *whence = (intptr_t*)&entry->item.util;
     ++		intptr_t *whence = (intptr_t*)&entry->value;
      +		*whence += amt;
      +	}
      +	else
     @@ strmap.c: void strmap_remove(struct strmap *map, const char *str, int free_util)
       ## strmap.h ##
      @@ strmap.h: static inline unsigned int strmap_get_size(struct strmap *map)
       		var = hashmap_iter_next_entry_offset(iter, \
     - 						OFFSETOF_VAR(var, ent)))
     + 						     OFFSETOF_VAR(var, ent)))
       
     ++
      +/*
     -+ * Helper functions for using strmap as map of string -> int, using the void*
     -+ * field to store the int instead of allocating an int and having the void*
     -+ * member point to the allocated int.
     ++ * strintmap:
     ++ *    A map of string -> int, typecasting the void* of strmap to an int.
     ++ *
     ++ * Primary differences:
     ++ *    1) Since the void* value is just an int in disguise, there is no value
     ++ *       to free.  (Thus one fewer argument to strintmap_clear)
     ++ *    2) strintmap_get() returns an int; it also requires an extra parameter to
     ++ *       be specified so it knows what value to return if the underlying strmap
     ++ *       has not key matching the given string.
     ++ *    3) No strmap_put() equivalent; strintmap_set() and strintmap_incr()
     ++ *       instead.
      + */
      +
     -+static inline int strintmap_get(struct strmap *map, const char *str,
     -+				int default_value)
     ++struct strintmap {
     ++	struct strmap map;
     ++};
     ++
     ++#define strintmap_for_each_entry(mystrmap, iter, var)	\
     ++	strmap_for_each_entry(&(mystrmap)->map, iter, var)
     ++
     ++static inline void strintmap_init(struct strintmap *map)
      +{
     -+	struct string_list_item *result = strmap_get_item(map, str);
     -+	if (!result)
     -+		return default_value;
     -+	return (intptr_t)result->util;
     ++	strmap_init(&map->map);
     ++}
     ++
     ++static inline void strintmap_ocd_init(struct strintmap *map,
     ++				      int strdup_strings)
     ++{
     ++	strmap_ocd_init(&map->map, strdup_strings);
      +}
      +
     -+static inline void strintmap_set(struct strmap *map, const char *str, intptr_t v)
     ++static inline void strintmap_clear(struct strintmap *map)
      +{
     -+	strmap_put(map, str, (void *)v);
     ++	strmap_clear(&map->map, 0);
      +}
      +
     -+void strintmap_incr(struct strmap *map, const char *str, intptr_t amt);
     ++static inline void strintmap_partial_clear(struct strintmap *map)
     ++{
     ++	strmap_partial_clear(&map->map, 0);
     ++}
     ++
     ++static inline int strintmap_contains(struct strintmap *map, const char *str)
     ++{
     ++	return strmap_contains(&map->map, str);
     ++}
      +
     -+static inline void strintmap_clear(struct strmap *map)
     ++static inline void strintmap_remove(struct strintmap *map, const char *str)
      +{
     -+	strmap_clear(map, 0);
     ++	return strmap_remove(&map->map, str, 0);
      +}
      +
     -+static inline void strintmap_free(struct strmap *map)
     ++static inline int strintmap_empty(struct strintmap *map)
      +{
     -+	strmap_free(map, 0);
     ++	return strmap_empty(&map->map);
      +}
     ++
     ++static inline unsigned int strintmap_get_size(struct strintmap *map)
     ++{
     ++	return strmap_get_size(&map->map);
     ++}
     ++
     ++static inline int strintmap_get(struct strintmap *map, const char *str,
     ++				int default_value)
     ++{
     ++	struct strmap_entry *result = strmap_get_entry(&map->map, str);
     ++	if (!result)
     ++		return default_value;
     ++	return (intptr_t)result->value;
     ++}
     ++
     ++static inline void strintmap_set(struct strintmap *map, const char *str,
     ++				 intptr_t v)
     ++{
     ++	strmap_put(&map->map, str, (void *)v);
     ++}
     ++
     ++void strintmap_incr(struct strintmap *map, const char *str, intptr_t amt);
      +
       #endif /* STRMAP_H */
  -:  ---------- >  9:  490d3a42ad strmap: add a strset sub-type
  4:  b3095d97d8 ! 10:  eca4f1ddba strmap: add strdup_strings option

@@ Metadata
Author: Elijah Newren <[email protected]>

## Commit message ##
- strmap: add strdup_strings option
+ strmap: enable allocations to come from a mem_pool

- Just as it is sometimes useful for string_list to duplicate and take
- ownership of memory management of the strings it contains, the same is
- sometimes true for strmaps as well. Add the same flag from string_list
- to strmap.
+ For heavy users of strmaps, allowing the keys and entries to be
+ allocated from a memory pool can provide significant overhead savings.
+ Add an option to strmap_ocd_init() to specify a memory pool.

## strmap.c ##
-@@ strmap.c: static struct str_entry *find_str_entry(struct strmap *map,
- return hashmap_get_entry(&map->map, &entry, ent, NULL);
+@@
+ #include "git-compat-util.h"
+ #include "strmap.h"
++#include "mem-pool.h"
+
+ static int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
+ const struct hashmap_entry *entry1,
+@@ strmap.c: static struct strmap_entry *find_strmap_entry(struct strmap *map, +
+ void strmap_init(struct strmap *map)
+ {
+- strmap_ocd_init(map, 1);
++ strmap_ocd_init(map, NULL, 1);
}

--void strmap_init(struct strmap *map)
-+void strmap_init(struct strmap *map, int strdup_strings)
+ void strmap_ocd_init(struct strmap *map,
++ struct mem_pool *pool,
+ int strdup_strings)
{
- hashmap_init(&map->map, cmp_str_entry, NULL, 0);
-+ map->strdup_strings = strdup_strings;
+ hashmap_init(&map->map, cmp_strmap_entry, NULL, 0);
++ map->pool = pool;
+ map->strdup_strings = strdup_strings;
}

- void strmap_free(struct strmap *map, int free_util)
-@@ strmap.c: void strmap_free(struct strmap *map, int free_util) +@@ strmap.c: static void strmap_free_entries_(struct strmap *map, int free_util)
if (!map)
return;

-- if (free_util) {
-+ if (map->strdup_strings || free_util) {
- hashmap_for_each_entry(&map->map, &iter, e, ent) {
-- free(e->item.string);
++ if (!free_util && map->pool)
++ /* Memory other than util is owned by and freed with the pool */
++ return;
++
+ /*
+ * We need to iterate over the hashmap entries and free
+ * e->key and e->value ourselves; hashmap has no API to
+@@ strmap.c: static void strmap_free_entries_(struct strmap *map, int free_util)
+ hashmap_for_each_entry(&map->map, &iter, e, ent) {
+ if (free_util)
+ free(e->value);
+- if (map->strdup_strings)
+- free((char*)e->key);
+- free(e);
++ if (!map->pool) {
+ if (map->strdup_strings)
-+ free(e->item.string);
- if (free_util)
- free(e->item.util);
- }
-@@ strmap.c: void strmap_free(struct strmap *map, int free_util)
- void strmap_clear(struct strmap *map, int free_util)
- {
- strmap_free(map, free_util);
-- strmap_init(map);
-+ strmap_init(map, map->strdup_strings);
++ free((char*)e->key);
++ free(e);
++ }
+ }
}

- /*
-- * Insert "str" into the map, pointing to "data". A copy of "str" is made, so -- * it does not need to persist after the this function is called.
-+ * Insert "str" into the map, pointing to "data".
- *
- * If an entry for "str" already exists, its data pointer is overwritten, and
- * the original data pointer returned. Otherwise, returns NULL.
@@ strmap.c: void *strmap_put(struct strmap *map, const char *str, void *data)
- } else {
- entry = xmalloc(sizeof(*entry));
+ */
+ const char *key = str;
+
+- entry = xmalloc(sizeof(*entry));
++ entry = map->pool ? mem_pool_alloc(map->pool, sizeof(*entry))
++ : xmalloc(sizeof(*entry));
hashmap_entry_init(&entry->ent, strhash(str));
-- entry->item.string = strdup(str);
-+ /*
-+ * We won't modify entry->item.string so it really should be
-+ * const, but changing string_list_item to use a const char *
-+ * is a bit too big of a change at this point.
-+ */
-+ entry->item.string =
-+ map->strdup_strings ? xstrdup(str) : (char *)str;
- entry->item.util = data;
+
+ if (map->strdup_strings)
+- key = xstrdup(str);
++ key = map->pool ? mem_pool_strdup(map->pool, str)
++ : xstrdup(str);
+ entry->key = key;
+ entry->value = data;
hashmap_add(&map->map, &entry->ent);
- }
@@ strmap.c: void strmap_remove(struct strmap *map, const char *str, int free_util)
- hashmap_entry_init(&entry.ent, strhash(str));
- entry.item.string = (char *)str;
- ret = hashmap_remove_entry(&map->map, &entry, ent, NULL);
-+ if (map->strdup_strings)
-+ free(ret->item.string);
- if (ret && free_util)
- free(ret->item.util);
- free(ret);
+ return;
+ if (free_util)
+ free(ret->value);
+- if (map->strdup_strings)
+- free((char*)ret->key);
+- free(ret);
++ if (!map->pool) {
++ if (map->strdup_strings)
++ free((char*)ret->key);
++ free(ret);
++ }
+ }
+
+ void strintmap_incr(struct strintmap *map, const char *str, intptr_t amt)

## strmap.h ##
@@

+ #include "hashmap.h"
+
++struct mempool;
struct strmap {
struct hashmap map;
-+ unsigned int strdup_strings:1;
++ struct mem_pool *pool;
+ unsigned int strdup_strings:1;
};

- struct str_entry {
-@@ strmap.h: struct str_entry {
- };
+@@ strmap.h: void strmap_init(struct strmap *map);

/*
-- * Initialize an empty strmap
-+ * Initialize the members of the strmap, set strdup_strings
-+ * member according to the value of the second parameter.
+ * Same as strmap_init, but for those who want to control the memory management +- * carefully instead of using the default of strdup_strings=1.
++ * carefully instead of using the default of strdup_strings=1 and pool=NULL.
+ * (OCD = Obsessive Compulsive Disorder, a joke that those who use this function
+ * are obsessing over minor details.)
*/
--void strmap_init(struct strmap *map);
-+void strmap_init(struct strmap *map, int strdup_strings);
+ void strmap_ocd_init(struct strmap *map,
++ struct mem_pool *pool,
+ int strdup_strings);

/*
- * Remove all entries from the map, releasing any allocated resources. -@@ strmap.h: void strmap_free(struct strmap *map, int free_values);
- void strmap_clear(struct strmap *map, int free_values); +@@ strmap.h: static inline void strintmap_init(struct strintmap *map)
+ }

- /*
-- * Insert "str" into the map, pointing to "data". A copy of "str" is made, so -- * it does not need to persist after the this function is called. -+ * Insert "str" into the map, pointing to "data".
- *
- * If an entry for "str" already exists, its data pointer is overwritten, and
- * the original data pointer returned. Otherwise, returns NULL.
+ static inline void strintmap_ocd_init(struct strintmap *map,
++ struct mem_pool *pool,
+ int strdup_strings)
+ {
+- strmap_ocd_init(&map->map, strdup_strings);
++ strmap_ocd_init(&map->map, pool, strdup_strings);
+ }
+
+ static inline void strintmap_clear(struct strintmap *map)
+@@ strmap.h: static inline void strset_init(struct strset *set)
+ }
+
+ static inline void strset_ocd_init(struct strset *set,
++ struct mem_pool *pool,
+ int strdup_strings)
+ {
+- strmap_ocd_init(&set->map, strdup_strings);
++ strmap_ocd_init(&set->map, pool, strdup_strings);
+ }
+
+ static inline void strset_clear(struct strset *set)

gitgitgadget

From: Elijah Newren <[email protected]>

The existence of hashmap_free() and hashmap_free_entries() confused me, and the docs weren't clear enough. We are dealing with a map table, entries in that table, and possibly also things each of those entries point to. I had to consult other source code examples and the implementation. Add a brief note to clarify the differences. This will become even more important once we introduce a new hashmap_partial_clear() function which will add the question of whether the table itself has been freed.

---
 hashmap.h | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

index b011b394fe..2994dc7a9c 100644
@@ -236,13 +236,40 @@ void hashmap_init(struct hashmap *map,
 void hashmap_free_(struct hashmap *map, ssize_t offset);
 
 /*
- * Frees a hashmap structure and allocated memory, leaves entries undisturbed
+ * Frees a hashmap structure and allocated memory for the table, but does not
+ * free the entries nor anything they point to.
+ *
+ * Usage note:
+ *
+ * Many callers will need to iterate over all entries and free the data each
+ * entry points to; in such a case, they can free the entry itself while at it.
+ * Thus, you might see:
+ *
+ *    hashmap_for_each_entry(map, hashmap_iter, e, hashmap_entry_name) {
+ *      free(e->somefield);
+ *      free(e);
+ *    }
+ *    hashmap_free(map);
+ *
+ * instead of
+ *
+ *    hashmap_for_each_entry(map, hashmap_iter, e, hashmap_entry_name) {
+ *      free(e->somefield);
+ *    }
+ *    hashmap_free_entries(map, struct my_entry_struct, hashmap_entry_name);
+ *
+ * to avoid the implicit extra loop over the entries.  However, if there are
+ * no special fields in your entry that need to be freed beyond the entry
+ * itself, it is probably simpler to avoid the explicit loop and just call
+ * hashmap_free_entries().
  */
 #define hashmap_free(map) hashmap_free_(map, -1)
 
 /*
  * Frees @map and all entries.  @type is the struct type of the entry
- * where @member is the hashmap_entry struct used to associate with @map
+ * where @member is the hashmap_entry struct used to associate with @map.
+ *
+ * See usage note above hashmap_free().
  */
 #define hashmap_free_entries(map, type, member) \
 	hashmap_free_(map, offsetof(type, member));

gitgitgadget

This is a definite improvement, and I don't see any inaccuracies in the descriptions. I do think some re-naming would help in the long run, though. E.g.:

- hashmap_clear() - remove all entries and de-allocate any hashmap-specific data, but be ready for reuse

- hashmap_clear_and_free() - ditto, but free the entries themselves

- hashmap_partial_clear() - remove all entries but don't deallocate table

- hashmap_partial_clear_and_free() - ditto, but free the entries

So always call it "clear", but allow options in two dimensions (partial or not, free entries or not).

Those could be parameters to a single function, but I think it gets a little ugly because "and_free" requires passing in the type of the entries in order to find the pointers.

The "not" cases are implied in the names, but hashmap_clear_full() would be OK with me, too.

But I think in the current scheme that "free" is somewhat overloaded, and if we end with a "clear" and a "free" that seems confusing to me.

-Peff

Hmm...there are quite a few calls to hashmap_free() and hashmap_free_entries() throughout the codebase. I'm wondering if I should make switching these over to your new naming suggestions a separate follow-on series from this one, so that if there are any conflicts with other series it doesn't need to hold these first 10 patches up.

If I do that, I could also add a patch to convert several callers of hashmap_init() to use the new HASHMAP_INIT() macro, and another patch to convert shortlog to using my strset instead of its own.

Yeah, it will definitely need a lot of mechanical fix-up. Those kinds of conflicts aren't usually a big deal. Junio will have to resolve them, but if the resolution is easy and mechanical, then it's not likely to hold up either topic.

Yeah, both would be nice. I'm happy if it comes as part of the series, or separately on top.

-Peff

After sending the email, I ended up deciding to convert the callers just to sanity check the HASHMAP_INIT macro and discovered that the code will BUG() if you don't also include .do_count_items = 1. So, I just decided to include that in the v3 of the series after all.

From: Elijah Newren <[email protected]>

No actual code changes; just whitespace adjustments.

---
 hashmap.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

index 09813e1a46..e44d8a3e85 100644
@@ -92,8 +92,9 @@ static void alloc_table(struct hashmap *map, unsigned int size)
 }
 
 static inline int entry_equals(const struct hashmap *map,
-		const struct hashmap_entry *e1, const struct hashmap_entry *e2,
-		const void *keydata)
+			       const struct hashmap_entry *e1,
+			       const struct hashmap_entry *e2,
+			       const void *keydata)
 {
 	return (e1 == e2) ||
 	       (e1->hash == e2->hash &&

@@ -101,7 +102,7 @@ static inline int entry_equals(const struct hashmap *map,
 }
 
 static inline unsigned int bucket(const struct hashmap *map,
-		const struct hashmap_entry *key)
+				  const struct hashmap_entry *key)
 {
 	return key->hash & (map->tablesize - 1);
 }

@@ -148,7 +149,7 @@ static int always_equal(const void *unused_cmp_data,
 }
 
 void hashmap_init(struct hashmap *map, hashmap_cmp_fn equals_function,
-		const void *cmpfn_data, size_t initial_size)
+		  const void *cmpfn_data, size_t initial_size)
 {
 	unsigned int size = HASHMAP_INITIAL_SIZE;
 

@@ -199,7 +200,7 @@ struct hashmap_entry *hashmap_get(const struct hashmap *map,
 }
 
 struct hashmap_entry *hashmap_get_next(const struct hashmap *map,
-			const struct hashmap_entry *entry)
+				       const struct hashmap_entry *entry)
 {
 	struct hashmap_entry *e = entry->next;
 	for (; e; e = e->next)

@@ -225,8 +226,8 @@ void hashmap_add(struct hashmap *map, struct hashmap_entry *entry)
 }
 
 struct hashmap_entry *hashmap_remove(struct hashmap *map,
-					const struct hashmap_entry *key,
-					const void *keydata)
+				     const struct hashmap_entry *key,
+				     const void *keydata)
 {
 	struct hashmap_entry *old;
 	struct hashmap_entry **e = find_entry_ptr(map, key, keydata);

@@ -249,7 +250,7 @@ struct hashmap_entry *hashmap_remove(struct hashmap *map,
 }
 
 struct hashmap_entry *hashmap_put(struct hashmap *map,
-				struct hashmap_entry *entry)
+				  struct hashmap_entry *entry)
 {
 	struct hashmap_entry *old = hashmap_remove(map, entry, NULL);
 	hashmap_add(map, entry);

gitgitgadget

Obviously good. Thanks for splitting this into its own patch.

-Peff

From: Elijah Newren <[email protected]>

Previously, once map->table had been freed, any calls to hashmap_put(), hashmap_get(), or hashmap_remove() would cause a NULL pointer dereference (since hashmap_free_() also zeros the memory; without that zeroing, calling these functions would cause a use-after-free problem).

Modify these functions to check for a NULL table and automatically allocate as needed.

I also thought about creating a HASHMAP_INIT macro to allow initializing hashmaps on the stack without calling hashmap_init(), but virtually all uses of hashmap specify a usecase-specific equals_function which defeats the utility of such a macro.

---
 hashmap.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

index e44d8a3e85..bb7c9979b8 100644
@@ -114,6 +114,7 @@ int hashmap_bucket(const struct hashmap *map, unsigned int hash)
 
 static void rehash(struct hashmap *map, unsigned int newsize)
 {
+	/* map->table MUST NOT be NULL when this function is called */
 	unsigned int i, oldsize = map->tablesize;
 	struct hashmap_entry **oldtable = map->table;
 

@@ -134,6 +135,7 @@ static void rehash(struct hashmap *map, unsigned int newsize)
 static inline struct hashmap_entry **find_entry_ptr(const struct hashmap *map,
 		const struct hashmap_entry *key, const void *keydata)
 {
+	/* map->table MUST NOT be NULL when this function is called */
 	struct hashmap_entry **e = &map->table[bucket(map, key)];
 	while (*e && !entry_equals(map, *e, key, keydata))
 		e = &(*e)->next;

@@ -196,6 +198,8 @@ struct hashmap_entry *hashmap_get(const struct hashmap *map,
 				const struct hashmap_entry *key,
 				const void *keydata)
 {
+	if (!map->table)
+		return NULL;
 	return *find_entry_ptr(map, key, keydata);
 }
 

@@ -211,8 +215,12 @@ struct hashmap_entry *hashmap_get_next(const struct hashmap *map,
 
 void hashmap_add(struct hashmap *map, struct hashmap_entry *entry)
 {
-	unsigned int b = bucket(map, entry);
+	unsigned int b;
+
+	if (!map->table)
+		alloc_table(map, HASHMAP_INITIAL_SIZE);
 
+	b = bucket(map, entry);
 	/* add entry */
 	entry->next = map->table[b];
 	map->table[b] = entry;

@@ -230,7 +238,11 @@ struct hashmap_entry *hashmap_remove(struct hashmap *map,
 				     const void *keydata)
 {
 	struct hashmap_entry *old;
-	struct hashmap_entry **e = find_entry_ptr(map, key, keydata);
+	struct hashmap_entry **e;
+
+	if (!map->table)
+		return NULL;
+	e = find_entry_ptr(map, key, keydata);
 	if (!*e)
 		return NULL;
 

gitgitgadget

Unsurprisingly, I like this direction. The code looks correct to me, though I think you could reduce duplication slightly by checking map->table in find_entry_ptr(). That covers both hashmap_get() and hashmap_remove(). But I'm happy either way.

This part I disagree with. If we did:

  #define HASHMAP_INIT(fn, data) = { .cmpfn = cmpfn, cmpfn_data = data }

then many callers could avoid handling the lazy-init themselves. E.g.:

 attr.c | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

index a826b2ef1f..55a2783f1b 100644
@@ -57,7 +57,9 @@ static inline void hashmap_unlock(struct attr_hashmap *map)
  * is a singleton object which is shared between threads.
  * Access to this dictionary must be surrounded with a mutex.
  */
-static struct attr_hashmap g_attr_hashmap;
+static struct attr_hashmap g_attr_hashmap = {
+	HASHMAP_INIT(attr_hash_entry_cmp, NULL)
+};
 
 /* The container for objects stored in "struct attr_hashmap" */
 struct attr_hash_entry {

@@ -80,12 +82,6 @@ static int attr_hash_entry_cmp(const void *unused_cmp_data,
 	return (a->keylen != b->keylen) || strncmp(a->key, b->key, a->keylen);
 }
 
-/* Initialize an 'attr_hashmap' object */
-static void attr_hashmap_init(struct attr_hashmap *map)
-{
-	hashmap_init(&map->map, attr_hash_entry_cmp, NULL, 0);
-}
-
 /*
  * Retrieve the 'value' stored in a hashmap given the provided 'key'.
  * If there is no matching entry, return NULL.

@@ -96,9 +92,6 @@ static void *attr_hashmap_get(struct attr_hashmap *map,
 	struct attr_hash_entry k;
 	struct attr_hash_entry *e;
 
-	if (!map->map.tablesize)
-		attr_hashmap_init(map);
-
 	hashmap_entry_init(&k.ent, memhash(key, keylen));
 	k.key = key;
 	k.keylen = keylen;

@@ -114,9 +107,6 @@ static void attr_hashmap_add(struct attr_hashmap *map,
 {
 	struct attr_hash_entry *e;
 
-	if (!map->map.tablesize)
-		attr_hashmap_init(map);
-
 	e = xmalloc(sizeof(struct attr_hash_entry));
 	hashmap_entry_init(&e->ent, memhash(key, keylen));
 	e->key = key;

Ah, gotcha. That makes sense to me. Given that 43 out of 47 callers of hashmap_init use cmpfn_data = NULL, should I shorten it to just one parameter for the macro, and let the four special cases keep calling hashmap_init() to specify a non-NULL cmpfn_data?

I'd be fine with it either way. I actually wrote it without the data parameter at first, then changed my mine and added it in. ;)

You could also do:

  #define HASHMAP_INIT_DATA(fn, data) { .cmpfn = cmpfn, cmpfn_data = data }
  #define HASHMAP_INIT(fn) HASHMAP_INIT_DATA(fn, NULL)

if you want to keep most callers simple.

-Peff

I ended up going with your HASHMAP_INIT(fn, data) in v3 that I submitted yesterday (except that you have a stray '=', are missing a '.' in front of cmpfn_data, and you'll trigger BUG()s if you don't also add .do_count_items = 1, but those are all minor fixups). In the future, if we determine we want/need the extra simplicity then we can always convert to this newer suggestion. I don't think it's that big a deal either way.

From: Elijah Newren <[email protected]>

merge-ort is a heavy user of strmaps, which are built on hashmap.[ch]. reset_maps() in merge-ort was taking about 12% of overall runtime in my testcase involving rebasing 35 patches of linux.git across a big rename. reset_maps() was calling hashmap_free() followed by hashmap_init(), meaning that not only was it freeing all the memory associated with each of the strmaps just to immediately allocate a new array again, it was allocating a new array that wasy likely smaller than needed (thus resulting in later need to rehash things). The ending size of the map table on the previous commit was likely almost perfectly sized for the next commit we wanted to pick, and not dropping and reallocating the table immediately is a win.

Add some new API to hashmap to clear a hashmap of entries without freeing map->table (and instead only zeroing it out like alloc_table() would do, along with zeroing the count of items in the table and the shrink_at field).

---
 hashmap.c | 39 +++++++++++++++++++++++++++------------
 hashmap.h | 13 ++++++++++++-
 2 files changed, 39 insertions(+), 13 deletions(-)

index bb7c9979b8..922ed07954 100644
@@ -174,22 +174,37 @@ void hashmap_init(struct hashmap *map, hashmap_cmp_fn equals_function,
 	map->do_count_items = 1;
 }
 
+static void free_individual_entries(struct hashmap *map, ssize_t entry_offset)
+{
+	struct hashmap_iter iter;
+	struct hashmap_entry *e;
+
+	hashmap_iter_init(map, &iter);
+	while ((e = hashmap_iter_next(&iter)))
+		/*
+		 * like container_of, but using caller-calculated
+		 * offset (caller being hashmap_free_entries)
+		 */
+		free((char *)e - entry_offset);
+}
+
+void hashmap_partial_clear_(struct hashmap *map, ssize_t entry_offset)
+{
+	if (!map || !map->table)
+		return;
+	if (entry_offset >= 0)  /* called by hashmap_clear_entries */
+		free_individual_entries(map, entry_offset);
+	memset(map->table, 0, map->tablesize * sizeof(struct hashmap_entry *));
+	map->shrink_at = 0;
+	map->private_size = 0;
+}
+
 void hashmap_free_(struct hashmap *map, ssize_t entry_offset)
 {
 	if (!map || !map->table)
 		return;
-	if (entry_offset >= 0) { /* called by hashmap_free_entries */
-		struct hashmap_iter iter;
-		struct hashmap_entry *e;
-
-		hashmap_iter_init(map, &iter);
-		while ((e = hashmap_iter_next(&iter)))
-			/*
-			 * like container_of, but using caller-calculated
-			 * offset (caller being hashmap_free_entries)
-			 */
-			free((char *)e - entry_offset);
-	}
+	if (entry_offset >= 0)  /* called by hashmap_free_entries */
+		free_individual_entries(map, entry_offset);
 	free(map->table);
 	memset(map, 0, sizeof(*map));
 }

index 2994dc7a9c..056a8cda32 100644
@@ -232,7 +232,8 @@ void hashmap_init(struct hashmap *map,
 			 const void *equals_function_data,
 			 size_t initial_size);
 
-/* internal function for freeing hashmap */
+/* internal functions for clearing or freeing hashmap */
+void hashmap_partial_clear_(struct hashmap *map, ssize_t offset);
 void hashmap_free_(struct hashmap *map, ssize_t offset);
 
 /*

@@ -265,6 +266,16 @@ void hashmap_free_(struct hashmap *map, ssize_t offset);
  */
 #define hashmap_free(map) hashmap_free_(map, -1)
 
+/*
+ * Basically the same as calling hashmap_free() followed by hashmap_init(),
+ * but doesn't incur the overhead of deallocating and reallocating
+ * map->table; it leaves map->table allocated and the same size but zeroes
+ * it out so it's ready for use again as an empty map.  As with
+ * hashmap_free(), you may need to free the entries yourself before calling
+ * this function.
+ */
+#define hashmap_partial_clear(map) hashmap_partial_clear_(map, -1)
+
 /*
  * Frees @map and all entries.  @type is the struct type of the entry
  * where @member is the hashmap_entry struct used to associate with @map.

gitgitgadget

s/wasy/was/

This seems like a reasonable optimization to make, and doesn't make the API significantly more complicated. I'd expect the allocation of actual entry objects to dwarf the table allocation, but I guess:

- you'll deal with the individual entries later using a mempool

- it's not just the allocation, but the re-insertion of the entries as we grow

It would be nice if we had some actual perf numbers to report here, so we could know exactly how much it was buying us. But I guess things are a bit out-of-order there. You want to do this series first and then build merge-ort on top as a user. We could introduce the basic data structure first, then merge-ort, and then start applying optimizations with real-world measurements. But I'm not sure it's worth the amount of time you'd have to spend to reorganize in that way.

The implementation itself looks correct to me. I already mentioned my thoughts on naming in patch 1.

-Peff

Thanks; will fix.

Yeah, the perf benefits didn't really come until I added a strmap_clear() based on this, so as you discovered I put perf numbers in patch 7 of this series. Should I add a mention of the later commit message at this point in the series?

I'll circle back to that when I comment on patch 1...

Nah, I think it's OK as it is. That kind of thing matters more for reviewing than when you find the commit later on. And we're already discussing it during the review.

-Peff

From: Elijah Newren <[email protected]>

Add strmap as a new struct and associated utility functions, specifically for hashmaps that map strings to some value. The API is taken directly from Peff's proposal at
https://lore.kernel.org/git/[email protected]/

A couple of items of note:

* Similar to string-list, I have a strdup_strings setting. However, unlike string-list, strmap_init() does not take a parameter for this setting and instead automatically sets it to 1; callers who want to control this detail need to instead call strmap_ocd_init().

* I do not have a STRMAP_INIT macro. I could possibly add one, but #define STRMAP_INIT { { NULL, cmp_str_entry, NULL, 0, 0, 0, 0, 0 }, 1 } feels a bit unwieldy and possibly error-prone in terms of future expansion of the hashmap struct. The fact that cmp_str_entry needs to be in there prevents us from passing all zeros for the hashmap, and makes me worry that STRMAP_INIT would just be more trouble than it is worth.

---
 Makefile |   1 +
 strmap.c | 102 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 strmap.h |  57 +++++++++++++++++++++++++++++++
 3 files changed, 160 insertions(+)
 create mode 100644 strmap.c
 create mode 100644 strmap.h

index 95571ee3fc..777a34c01c 100644
@@ -1000,6 +1000,7 @@ LIB_OBJS += stable-qsort.o
 LIB_OBJS += strbuf.o
 LIB_OBJS += streaming.o
 LIB_OBJS += string-list.o
+LIB_OBJS += strmap.o
 LIB_OBJS += strvec.o
 LIB_OBJS += sub-process.o
 LIB_OBJS += submodule-config.o

gitgitgadget

This looks overall sane to me. I mentioned elsewhere that we could be using FLEXPTR_ALLOC to save an extra allocation. I think it's easy and worth doing here, as the logic would be completely contained within strmap_put():

if (strdup_strings)

	FLEXPTR_ALLOC_STR(entry, key, str);
  else {
	entry = xmalloc(sizeof(*entry));
	entry->key = str;

}

And free_entries() then doesn't even have to care about strdup_strings.

That seems reasonable. It could just be a parameter, but I like that you push people in the direction of doing the simple and safe thing, rather than having them wonder whether they ought to set strdup_strings or not.

You can actually omit everything after cmp_str_entry, and those fields would all get zero-initialized. But we also allow C99 designed initializers these days. Coupled with the HASHMAP_INIT() I mentioned in the earlier email, you'd have:

  #define STRMAP_INIT { \
		.map = HASHMAP_INIT(cmp_strmap_entry, NULL), \
		.strdup_strings = 1, \
	  }

which seems pretty maintainable.

You use the term "value" for the mapped-to value in this iteration. So perhaps free_values here (and in other functions) would be a better name?

  const char *one = xstrdup("foo");
  const char *two = xstrdup("foo");

  hashmap_put(map, one, x);
  hashmap_put(map, two, y);

Yeah, as you noted in your review of 10/10 this idea wouldn't play well with the later mem_pool changes.

Well, in my first round of the series where I did make it a parameter you balked pretty loudly. ;-)

Makes sense; will add.

Oops, yes, definitely.

I'll keep mulling it over, but I likewise can't currently think of a case where it'd matter.

Either I was (mistakenly) worried about "I'm going to allocate and copy, but during the copy it isn't actually const", or this is a leftover artifact from some of the other iterations I tried. Anyway, I think this comment isn't useful; I'll just strike it.

Yep, addressed later by strmap_get_entry() in another patch, as you noticed in your later review.

Doh! That's going to push a bunch of lines past 80 characters. Sigh...

It's probably a better name though; I'll change it.

From: Elijah Newren <[email protected]>

This adds a number of additional convienence functions I want/need:
* strmap_empty()
* strmap_get_size()
* strmap_remove()
* strmap_for_each_entry()
* strmap_get_entry()

I suspect the first four are self-explanatory.

strmap_get_entry() is similar to strmap_get() except that instead of just returning the void* value that the string maps to, it returns the strmap_entry that contains both the string and the void* value (or NULL if the string isn't in the map). This is helpful because it avoids multiple lookups, e.g. in some cases a caller would need to call:
* strmap_contains() to check that the map has an entry for the string
* strmap_get() to get the void* value
* <do some work to update the value>
* strmap_put() to update/overwrite the value
If the void* pointer returned really is a pointer, then the last step is unnecessary, but if the void* pointer is just cast to an integer then strmap_put() will be needed. In contrast, one can call strmap_get_entry() and then:
* check if the string was in the map by whether the pointer is NULL
* access the value via entry->value
* directly update entry->value
meaning that we can replace two or three hash table lookups with one.

---
 strmap.c | 20 ++++++++++++++++++++
 strmap.h | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 58 insertions(+)

index 4b48d64274..909b9fbedf 100644
@@ -90,6 +90,11 @@ void *strmap_put(struct strmap *map, const char *str, void *data)
 	return old;
 }
 
+struct strmap_entry *strmap_get_entry(struct strmap *map, const char *str)
+{
+	return find_strmap_entry(map, str);
+}
+
 void *strmap_get(struct strmap *map, const char *str)
 {
 	struct strmap_entry *entry = find_strmap_entry(map, str);

@@ -100,3 +105,18 @@ int strmap_contains(struct strmap *map, const char *str)
 {
 	return find_strmap_entry(map, str) != NULL;
 }
+
+void strmap_remove(struct strmap *map, const char *str, int free_util)
+{
+	struct strmap_entry entry, *ret;
+	hashmap_entry_init(&entry.ent, strhash(str));
+	entry.key = str;
+	ret = hashmap_remove_entry(&map->map, &entry, ent, NULL);
+	if (!ret)
+		return;
+	if (free_util)
+		free(ret->value);
+	if (map->strdup_strings)
+		free((char*)ret->key);
+	free(ret);
+}

index 493d19cbc0..e49d020970 100644
@@ -42,6 +42,12 @@ void strmap_clear(struct strmap *map, int free_values);
  */
 void *strmap_put(struct strmap *map, const char *str, void *data);
 
+/*
+ * Return the strmap_entry mapped by "str", or NULL if there is not such
+ * an item in map.
+ */
+struct strmap_entry *strmap_get_entry(struct strmap *map, const char *str);
+
 /*
  * Return the data pointer mapped by "str", or NULL if the entry does not
  * exist.

@@ -54,4 +60,36 @@ void *strmap_get(struct strmap *map, const char *str);
  */
 int strmap_contains(struct strmap *map, const char *str);
 
+/*
+ * Remove the given entry from the strmap.  If the string isn't in the
+ * strmap, the map is not altered.
+ */
+void strmap_remove(struct strmap *map, const char *str, int free_value);
+
+/*
+ * Return whether the strmap is empty.
+ */
+static inline int strmap_empty(struct strmap *map)
+{
+	return hashmap_get_size(&map->map) == 0;
+}
+
+/*
+ * Return how many entries the strmap has.
+ */
+static inline unsigned int strmap_get_size(struct strmap *map)
+{
+	return hashmap_get_size(&map->map);
+}
+
+/*
+ * iterate through @map using @iter, @var is a pointer to a type strmap_entry
+ */
+#define strmap_for_each_entry(mystrmap, iter, var)	\
+	for (var = hashmap_iter_first_entry_offset(&(mystrmap)->map, iter, \
+						   OFFSETOF_VAR(var, ent)); \
+		var; \
+		var = hashmap_iter_next_entry_offset(iter, \
+						     OFFSETOF_VAR(var, ent)))
+
 #endif /* STRMAP_H */

gitgitgadget

Oh, I guess I should have read ahead when responding to the last patch. :)

Yes, this function makes perfect sense to have (along with the simpler alternatives for the callers that don't need this complexity).

The implementation all looks pretty straight-forward.

  return strmap_get_size(&map) == 0;

Makes sense; will change it.

Actually, since we know ent is the first entry in strmap, the offset is always 0. So can't we just avoid OFFSETOF_VAR() and offsetof() entirely, by just using hashmap_iter_first() and hashmap_iter_next()? I'm going to try that.

Yes, I think that would work fine. You may want to add a comment to the struct indicating that it's important for the hashmap_entry to be at the front of the struct. Using offsetof() means that it's impossible to get it wrong, though.

-Peff

From: Elijah Newren <[email protected]>

When strmaps are used heavily, such as is done by my new merge-ort algorithm, and strmaps need to be cleared but then re-used (because of e.g. picking multiple commits to cherry-pick, or due to a recursive merge having several different merges while recursing), free-ing and reallocating map->table repeatedly can add up in time, especially since it will likely be reallocated to a much smaller size but the previous merge provides a good guide to the right size to use for the next merge.

Introduce strmap_partial_clear() to take advantage of this type of situation; it will act similar to strmap_clear() except that map->table's entries are zeroed instead of map->table being free'd. Making use of this function reduced the cost of reset_maps() by about 20% in mert-ort, and dropped the overall runtime of my rebase testcase by just under 2%.

---
 strmap.c | 6 ++++++
 strmap.h | 6 ++++++
 2 files changed, 12 insertions(+)

index 909b9fbedf..47cbf11ec7 100644
@@ -64,6 +64,12 @@ void strmap_clear(struct strmap *map, int free_util)
 	hashmap_free(&map->map);
 }
 
+void strmap_partial_clear(struct strmap *map, int free_util)
+{
+	strmap_free_entries_(map, free_util);
+	hashmap_partial_clear(&map->map);
+}
+
 void *strmap_put(struct strmap *map, const char *str, void *data)
 {
 	struct strmap_entry *entry = find_strmap_entry(map, str);

index e49d020970..5bb7650d65 100644
@@ -34,6 +34,12 @@ void strmap_ocd_init(struct strmap *map,
  */
 void strmap_clear(struct strmap *map, int free_values);
 
+/*
+ * Similar to strmap_clear() but leaves map->map->table allocated and
+ * pre-sized so that subsequent uses won't need as many rehashings.
+ */
+void strmap_partial_clear(struct strmap *map, int free_values);
+
 /*
  * Insert "str" into the map, pointing to "data".
  *

gitgitgadget

Oh, these were the real numbers I was looking for earlier. :)

Of course it's a little confusing because reset_maps() doesn't exist yet in the code base this is being applied on, but I can live with that.

From: Elijah Newren <[email protected]>

Although strmap could be used as a string->int map, one either had to allocate an int for every entry and then deallocate later, or one had to do a bunch of casting between (void*) and (intptr_t).

Add some special functions that do the casting. Also, rename put->set for such wrapper functions since 'put' implied there may be some deallocation needed if the string was already found in the map, which isn't the case when we're storing an int value directly in the void* slot instead of using the void* slot as a pointer to data.

A note on the name: if anyone has a better name suggestion than strintmap, I'm happy to take it. It seems slightly unwieldy, but I have not been able to come up with a better name.

---
 strmap.c | 11 ++++++++
 strmap.h | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 91 insertions(+)

index 47cbf11ec7..d5003a79e3 100644
@@ -126,3 +126,14 @@ void strmap_remove(struct strmap *map, const char *str, int free_util)
 		free((char*)ret->key);
 	free(ret);
 }
+
+void strintmap_incr(struct strintmap *map, const char *str, intptr_t amt)
+{
+	struct strmap_entry *entry = find_strmap_entry(&map->map, str);
+	if (entry) {
+		intptr_t *whence = (intptr_t*)&entry->value;
+		*whence += amt;
+	}
+	else
+		strintmap_set(map, str, amt);
+}

gitgitgadget

I think this is worth doing. That kind of casting is an implementation detail, and it's nice for callers not to have to see it.

You might want to mention that this _could_ be done as just accessors to strmap, but using a separate struct provides type safety against misusing pointers as integers or vice versa.

I still don't have a better suggestion on the name. Another convention could be to name map types as "map_from_to". So "struct map_str_int". But it's pretty ugly, and strmap would become "map_str_ptr" or something. As ugly as "strintmap" is, I like it better.

Are the size and signedness of an int flexible enough for all uses?

I doubt the standard makes any promises about the relationship between intptr_t and int, but I'd be surprised if any modern platform has an intptr_t that isn't at least as big as an int (on most 32-bit platforms they'll be the same, and on 64-bit ones intptr_t is strictly bigger).

Would any callers care about using the full 32-bits, though? I.e., would they prefer casting through uintptr_t to an "unsigned int"?

-Peff

If I just did it as accessors, it makes it harder for myself and others to remember what my huge piles of strmaps in merge-ort do; I found that it became easier to follow the code and remember what things were doing when some were marked as strmap, some as strintmap, and some as strset.

That probably makes sense. It turns out there is one strintmap for which I call strintmap_get() in two different places with different default values, but I think I can fix that up (one of them really needed -1 as the default, while the other callsite just needed the default to not accidentally match a specific enum value and 0 was convenient).

If some users want signed values and others want unsigned, I'm not sure how we can satisfy both. Maybe make a struintmap?

Perhaps that could be added later if uses come up for it? Some of my uses need int, the rest of them wouldn't care about int vs unsigned.

I don't care about the full 32 bits (I'll probably use less than 16), but I absolutely wanted it signed for my uses. I think it makes sense to be signed when using it for an index within an array (-1 for "not found" makes sense; using arbitrary large numbers seems really ugly (and perhaps buggy) to me). It also makes sense to me to use -1 as an invalid enum value, though I guess I could technically specify an additional "INVALID_VALUE" within the enum and use it as the default.

If someone does care about the full range of bits up to 64 on relevant platforms, I guess I should make it strintptr_t_map. But besides the egregiously ugly name, one advantage of int over intptr_t (or unsigned over uintptr_t) is that you can use it in a printf easily:
printf("Size: %d\n", strintmap_get(&foo, 0));
whereas if it strintmap_get() returns an intptr_t, then it's a royal mess to attempt to portably use it without adding additional manual casts. Maybe I was just missing something obvious, but I couldn't figure out the %d, %ld, %lld, PRIdMAX, etc. choices and get the statement to compile on all platforms, so I'd always just cast to int or unsigned at the time of calling printf.

Oh, I'm definitely on board with that argument. I was just suggesting you might want to put it in the commit message for posterity.

Right, that was sort of my question: do your users actually want it signed or not. Sounds like they do want it signed, and don't mind the loss of range.

Yeah, if you don't have any callers which care, I'd definitely punt on it for now.

Yeah, that's what I was wondering. I suspect the use case for that is pretty narrow, though. If you really care about having a 64-bit value for some data, then you probably want it _everywhere_, not just on 64-bit platforms. I guess the exception would be if you're mapping into size_t's or something.

I think my question was as much "did you think about range issues for your intended users" as "should we provide more range in this map type". And it sounds like you have thought about that, so I'm happy proceeding.

The right way is:

  printf("Size: %"PRIdMAX", (intmax_t) your_intptr_t);

which will always do the right thing no matter the size (at the minor cost of passing a larger-than-necessary parameter, but if you're micro-optimizing then calling printf at all is probably already a problem).

But yeah, in general using a real "int" is much more convenient and if there's no reason to avoid it for range problems, I think it's preferable.

-Peff

Ah, intmax_t; that's what I was missing.

Yep, I like the simplicity of "int", the signedness of "int" and it has far more than enough range on all platforms (most my strintmaps actually map to enum values, but my largest int usage is for counting up to at most how many files are involved in rename detection. Even microsoft repos only have a number of files present in the repository that registers in the low millions, and I'm only dealing with the subset of those files involved in rename detection, which should be much smaller).

From: Elijah Newren <[email protected]>

Similar to adding strintmap for special-casing a string -> int mapping, add a strset type for cases where we really are only interested in using strmap for storing a set rather than a mapping. In this case, we'll always just store NULL for the value but the different struct type makes it clearer than code comments how a variable is intended to be used.

The difference in usage also results in some differences in API: a few things that aren't necessary or meaningful are dropped (namely, the free_util argument to *_clear(), and the *_get() function), and strset_add() is chosen as the API instead of strset_put().

---
 strmap.h | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)

index fe15e74b78..2ad6696950 100644
@@ -178,4 +178,68 @@ static inline void strintmap_set(struct strintmap *map, const char *str,
 
 void strintmap_incr(struct strintmap *map, const char *str, intptr_t amt);
 
+/*
+ * strset:
+ *    A set of strings.
+ *
+ * Primary differences with strmap:
+ *    1) The value is always NULL, and ignored.  As there is no value to free,
+ *       there is one fewer argument to strset_clear
+ *    2) No strset_get() because there is no value.
+ *    3) No strset_put(); use strset_add() instead.
+ */
+
+struct strset {
+	struct strmap map;
+};
+
+#define strset_for_each_entry(mystrset, iter, var)	\
+	strmap_for_each_entry(&(mystrset)->map, iter, var)
+
+static inline void strset_init(struct strset *set)
+{
+	strmap_init(&set->map);
+}
+
+static inline void strset_ocd_init(struct strset *set,
+				   int strdup_strings)
+{
+	strmap_ocd_init(&set->map, strdup_strings);
+}
+
+static inline void strset_clear(struct strset *set)
+{
+	strmap_clear(&set->map, 0);
+}
+
+static inline void strset_partial_clear(struct strset *set)
+{
+	strmap_partial_clear(&set->map, 0);
+}
+
+static inline int strset_contains(struct strset *set, const char *str)
+{
+	return strmap_contains(&set->map, str);
+}
+
+static inline void strset_remove(struct strset *set, const char *str)
+{
+	return strmap_remove(&set->map, str, 0);
+}
+
+static inline int strset_empty(struct strset *set)
+{
+	return strmap_empty(&set->map);
+}
+
+static inline unsigned int strset_get_size(struct strset *set)
+{
+	return strmap_get_size(&set->map);
+}
+
+static inline void strset_add(struct strset *set, const char *str)
+{
+	strmap_put(&set->map, str, NULL);
+}
+
 #endif /* STRMAP_H */

gitgitgadget

That all makes sense.

We're wasting 8 bytes of NULL pointer for each entry, but it's unlikely to be all that important. If we later find a case where we think it matters, we can always refactor the type not to depend on strmap.

I'd want a strset_check_and_add() to match what I used recently in shortlog.h. Maybe strset_contains_and_add() would be a better name to match the individual functions here. I dunno (it actually seems clunkier).

-Peff

Yeah, I'll just go with strset_check_and_add(). :-)

From: Elijah Newren <[email protected]>

For heavy users of strmaps, allowing the keys and entries to be allocated from a memory pool can provide significant overhead savings. Add an option to strmap_ocd_init() to specify a memory pool.

---
 strmap.c | 31 ++++++++++++++++++++++---------
 strmap.h | 11 ++++++++---
 2 files changed, 30 insertions(+), 12 deletions(-)

index d5003a79e3..83b9de961c 100644
@@ -1,5 +1,6 @@
 #include "git-compat-util.h"
 #include "strmap.h"
+#include "mem-pool.h"
 
 static int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
 			    const struct hashmap_entry *entry1,

@@ -24,13 +25,15 @@ static struct strmap_entry *find_strmap_entry(struct strmap *map,
 
 void strmap_init(struct strmap *map)
 {
-	strmap_ocd_init(map, 1);
+	strmap_ocd_init(map, NULL, 1);
 }
 
 void strmap_ocd_init(struct strmap *map,
+		     struct mem_pool *pool,
 		     int strdup_strings)
 {
 	hashmap_init(&map->map, cmp_strmap_entry, NULL, 0);
+	map->pool = pool;
 	map->strdup_strings = strdup_strings;
 }
 

@@ -42,6 +45,10 @@ static void strmap_free_entries_(struct strmap *map, int free_util)
 	if (!map)
 		return;
 
+	if (!free_util && map->pool)
+		/* Memory other than util is owned by and freed with the pool */
+		return;
+
 	/*
 	 * We need to iterate over the hashmap entries and free
 	 * e->key and e->value ourselves; hashmap has no API to

@@ -52,9 +59,11 @@ static void strmap_free_entries_(struct strmap *map, int free_util)
 	hashmap_for_each_entry(&map->map, &iter, e, ent) {
 		if (free_util)
 			free(e->value);
-		if (map->strdup_strings)
-			free((char*)e->key);
-		free(e);
+		if (!map->pool) {
+			if (map->strdup_strings)
+				free((char*)e->key);
+			free(e);
+		}
 	}
 }
 

@@ -84,11 +93,13 @@ void *strmap_put(struct strmap *map, const char *str, void *data)
 		 */
 		const char *key = str;
 
-		entry = xmalloc(sizeof(*entry));
+		entry = map->pool ? mem_pool_alloc(map->pool, sizeof(*entry))
+				  : xmalloc(sizeof(*entry));
 		hashmap_entry_init(&entry->ent, strhash(str));
 
 		if (map->strdup_strings)
-			key = xstrdup(str);
+			key = map->pool ? mem_pool_strdup(map->pool, str)
+					: xstrdup(str);
 		entry->key = key;
 		entry->value = data;
 		hashmap_add(&map->map, &entry->ent);

@@ -122,9 +133,11 @@ void strmap_remove(struct strmap *map, const char *str, int free_util)
 		return;
 	if (free_util)
 		free(ret->value);
-	if (map->strdup_strings)
-		free((char*)ret->key);
-	free(ret);
+	if (!map->pool) {
+		if (map->strdup_strings)
+			free((char*)ret->key);
+		free(ret);
+	}
 }
 
 void strintmap_incr(struct strintmap *map, const char *str, intptr_t amt)

index 2ad6696950..b93b7c9fd6 100644
@@ -3,8 +3,10 @@
 
 #include "hashmap.h"
 
+struct mempool;
 struct strmap {
 	struct hashmap map;
+	struct mem_pool *pool;
 	unsigned int strdup_strings:1;
 };
 

@@ -22,11 +24,12 @@ void strmap_init(struct strmap *map);
 
 /*
  * Same as strmap_init, but for those who want to control the memory management
- * carefully instead of using the default of strdup_strings=1.
+ * carefully instead of using the default of strdup_strings=1 and pool=NULL.
  * (OCD = Obsessive Compulsive Disorder, a joke that those who use this function
  * are obsessing over minor details.)
  */
 void strmap_ocd_init(struct strmap *map,
+		     struct mem_pool *pool,
 		     int strdup_strings);
 
 /*

@@ -126,9 +129,10 @@ static inline void strintmap_init(struct strintmap *map)
 }
 
 static inline void strintmap_ocd_init(struct strintmap *map,
+				      struct mem_pool *pool,
 				      int strdup_strings)
 {
-	strmap_ocd_init(&map->map, strdup_strings);
+	strmap_ocd_init(&map->map, pool, strdup_strings);
 }
 
 static inline void strintmap_clear(struct strintmap *map)

@@ -202,9 +206,10 @@ static inline void strset_init(struct strset *set)
 }
 
 static inline void strset_ocd_init(struct strset *set,
+				   struct mem_pool *pool,
 				   int strdup_strings)
 {
-	strmap_ocd_init(&set->map, strdup_strings);
+	strmap_ocd_init(&set->map, pool, strdup_strings);
 }
 
 static inline void strset_clear(struct strset *set)

gitgitgadget

So this one interacts badly with my FLEXPTR suggestion.

I guess it provides most of the benefit that FLEXPTR would, because we're getting both the entries and the strings from the mempool. Which really ends up being an almost identical memory layout, since the mempool presumably just gives you the N bytes for the string right after the last thing you allocated, which would be the struct.

The only downside is that if you don't want to use the mempool (e.g., because you might actually strmap_remove() things), you don't get the advantage.

I think we could fall back to a FLEXPTR when there's no mempool (or even when there is, though you'd be on your own to reimplement the computation parts of FLEXPTR_ALLOC). I'm not sure how ugly it would end up.

I haven't used our mem_pool before, but the code all looks quite straightforward to me. I guess the caller is responsible for de-allocating the mempool, which makes sense. It would be nice to see real numbers on how much this helps, but again, you might not have the commits in the right order to easily find out.

-Peff

Yeah, we'd need a mempool-specific reimplementation of FLEXPTR_ALLOC with the mempool, and just avoid using it at all whenever strdup_strings was 0. Seems slightly ugly, but maybe it wouldn't be too bad. I could look into it.

At the time I implemented it, I did grab some numbers. It varied quite a bit between different cases, since a lot of my strmaps are for tracking when special cases arise and we can implement various optimizations. Naturally, a usecase which involves heavier use of strmaps will mean greater benefits from using a mempool. Also, if I had implemented it later, after one rename-related optimization I hadn't yet discovered at the time, then it would have shown a larger relative reduction in overall execution time. Anyway, at the time I put the mempool into strmaps and made use of it in relevant places, one of my rebase testcases saw an almost 5% reduction in overall execution time. I'm sure it would have been over 5% if I had reordered it to come after my final rename optimization.

It looks like you went this route (fall back to FLEXPTR) in the re-roll you posted. I haven't looked at it carefully yet, but I suspect it will be just fine to me (I probably would have accepted "no, it makes the code too ugly; if you want efficiency use a mempool" as well, but I'll see how ugly it turned out. ;) ).

Thanks, it's nice to have a ballpark like that. It might be worth putting it into the commit message, even if it's hand-wavy:

This seemed to provide about 5% speedup for some rebase test cases I ran. Unfortunately you can't just time this commit and its parent, since we aren't yet actually using strmap in the code yet.

But again, I think the main value of that is during review, so if it doesn't make it into the commit message, I'm OK.

-Peff

Here I introduce a new strmap type (and strintmap and strset), which my new merge backed, merge-ort, uses heavily. (I also made significant use of it in my changes to diffcore-rename). This strmap type was based on Peff's proposal from a couple years ago[1], but has additions that I made as I used it, and a number of additions/changes suggested by Peff in his reviews. I also start the series off with some changes to hashmap, based on Peff's feedback on v1 & v2.

NOTE: My "fundamentals of merge-ort implementation"[2] that depends on this series needs to be updated due to these changes. I'll send a reroll for it soon.

Changes since v2 (almost all of which were suggestions from Peff):

* Added HASHMAP_INIT() and STR*_INIT() macros (and added a patch converting some existing callsites to use them)
* Introduced the improved hashmap deallocation function names that Peff suggested and updated the codebase (currently merges cleanly with seen, though there's always a risk someone else is introducing a new one, but it's at least clean right now)
* Renamed free_util -> free_values, everywhere this time
* Renamed strmap_ocd_init() -> strmap_init_with_options(). Similar for the other str* subtypes.
* Implemented strmap_empty() on top of strmap_get_size() instead of hashmap_get_size()
* Avoided the OFFSETOF_VAR initialization-on-windows concerns by just not using the macro; for strmap_entry, the offset is always 0
* Stored the default_value for a strintmap in the strintmap rather than requiring it at every call to strintmap_get(). Updated strintmap_incr() to make use of it as well.
* Add a strset_check_and_add() function to the API
* Added an extra patch at the end to take advantage of FLEXPTR_ALLOC_STR in the default case to avoid an extra allocation and free.
* Tweaked some commit messages, fixed a few more argument-alignment issues, removed a bad comment

Things that I'm still unsure about:

* strintmap_init() takes a default_value parameter, as suggested by Peff. But this makes the function name strintmap_init_with_options() weird, because strintmap_init() already takes one option, so it seems like the name needs to replace "options" with "more_options". But that's kinda ugly too. I'm guessing strintmap_init_with_options() is fine as-is, but I'm wondering if anyone else thinks it looks weird and if so if there is anything I should do about it.

Things Peff mentioned on v2 that I did NOT do:

* Peff brought up some questions about mapping strintmap to an int rather than an unsigned or intptr_t. I discussed my rationale in the thread

Things Peff mentioned on v1 that are still not included and which Peff didn't comment on for v2, but which may still be worth mentioning again:

* Peff brought up the idea of having a free_values member instead of having a free_values parameter to strmap_clear(). That'd just mean moving the parameter from strmap_clear() to strmap_init() and would be easy to do, but he sounded like he was just throwing it out as an idea and I didn't have a strong opinion, so I left it as-is. If others have opinions/preferences, changing it is easy right now.
* Peff early on wanted the strmap_entry type to have a char key[FLEX_ALLOC] instead of having a (const) char *key. I spent a couple more days on this despite him not mentioning it while reviewing v2, and finally got it working this time and running valgrind-free. Note that such a change means always copying the key instead of allowing it as an option. After implementing it, I timed it and it slowed down my important testcase by just over 6%. So I chucked it. I think the FLEXPTR_ALLOC_STR usage in combination with defaulting to strdup_strings=1 gives us most the benefits Peff wanted, while still allowing merge-ort to reuse strings when it's important.

[1]
https://lore.kernel.org/git/[email protected]/[2]
https://lore.kernel.org/git/CABPp-BHKGkx04neULtYUyfiU+z-X7_rxQqriSEjxZjU1oXokOA@mail.gmail.com/T/#t
[3]
https://lore.kernel.org/git/CABPp-BFyqTthyBmp5yt+iUniwTi+=y2QcBcmNnnCy=zvyi3Rbw@mail.gmail.com/

Elijah Newren (13):
hashmap: add usage documentation explaining hashmap_free[_entries]()
hashmap: adjust spacing to fix argument alignment
hashmap: allow re-use after hashmap_free()
hashmap: introduce a new hashmap_partial_clear()
hashmap: provide deallocation function names
strmap: new utility functions
strmap: add more utility functions
strmap: enable faster clearing and reusing of strmaps
strmap: add functions facilitating use as a string->int map
strmap: add a strset sub-type
strmap: enable allocations to come from a mem_pool
strmap: take advantage of FLEXPTR_ALLOC_STR when relevant Use new HASHMAP_INIT macro to simplify hashmap initialization

 Makefile                |   1 +
 add-interactive.c       |   2 +-
 attr.c                  |  26 ++--
 blame.c                 |   2 +-
 bloom.c                 |   5 +-
 builtin/difftool.c      |   9 +-
 builtin/fetch.c         |   6 +-
 builtin/shortlog.c      |   2 +-
 config.c                |   2 +-
 diff.c                  |   4 +-
 diffcore-rename.c       |   2 +-
 dir.c                   |   8 +-
 hashmap.c               |  74 +++++++----
 hashmap.h               |  91 ++++++++++---
 merge-recursive.c       |   6 +-
 name-hash.c             |   4 +-
 object.c                |   2 +-
 oidmap.c                |   2 +-
 patch-ids.c             |   2 +-
 range-diff.c            |   6 +-
 ref-filter.c            |   2 +-
 revision.c              |  11 +-
 sequencer.c             |   4 +-
 strmap.c                | 158 +++++++++++++++++++++++
 strmap.h                | 280 ++++++++++++++++++++++++++++++++++++++++
 submodule-config.c      |   4 +-
 t/helper/test-hashmap.c |   9 +-
 27 files changed, 610 insertions(+), 114 deletions(-)
 create mode 100644 strmap.c
 create mode 100644 strmap.h

base-commit: d4a392452e292ff924e79ec8458611c0f679d6d4
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-835%2Fnewren%2Fstrmap-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-835/newren/strmap-v3
Pull-Request: https://github.com/git/git/pull/835

Range-diff vs v2:

  1:  af6b6fcb46 =  1:  af6b6fcb46 hashmap: add usage documentation explaining hashmap_free[_entries]()
  2:  75f17619e9 !  2:  591161fd78 hashmap: adjust spacing to fix argument alignment

@@ hashmap.c: struct hashmap_entry *hashmap_remove(struct hashmap *map,
{
struct hashmap_entry *old = hashmap_remove(map, entry, NULL); hashmap_add(map, entry);
+
+ ## hashmap.h ##
+@@ hashmap.h: struct hashmap {
+ * prevent expensive resizing. If 0, the table is dynamically resized.
+ */
+ void hashmap_init(struct hashmap *map,
+- hashmap_cmp_fn equals_function,
+- const void *equals_function_data,
+- size_t initial_size);
++ hashmap_cmp_fn equals_function,
++ const void *equals_function_data,
++ size_t initial_size);
+
+ /* internal function for freeing hashmap */
+ void hashmap_free_(struct hashmap *map, ssize_t offset);
+@@ hashmap.h: void hashmap_free_(struct hashmap *map, ssize_t offset);
+ * and if it is on stack, you can just let it go out of scope).
+ */
+ static inline void hashmap_entry_init(struct hashmap_entry *e,
+- unsigned int hash)
++ unsigned int hash)
+ {
+ e->hash = hash;
+ e->next = NULL;
+@@ hashmap.h: static inline unsigned int hashmap_get_size(struct hashmap *map)
+ * to hashmap_cmp_fn to decide whether the entry matches the key.
+ */
+ struct hashmap_entry *hashmap_get(const struct hashmap *map,
+- const struct hashmap_entry *key,
+- const void *keydata);
++ const struct hashmap_entry *key,
++ const void *keydata);
+
+ /*
+ * Returns the hashmap entry for the specified hash code and key data, +@@ hashmap.h: static inline struct hashmap_entry *hashmap_get_from_hash(
+ * call to hashmap_get or hashmap_get_next.
+ */
+ struct hashmap_entry *hashmap_get_next(const struct hashmap *map,
+- const struct hashmap_entry *entry);
++ const struct hashmap_entry *entry);
+
+ /*
+ * Adds a hashmap entry. This allows to add duplicate entries (i.e. +@@ hashmap.h: void hashmap_add(struct hashmap *map, struct hashmap_entry *entry);
+ * Returns the replaced entry, or NULL if not found (i.e. the entry was added).
+ */
+ struct hashmap_entry *hashmap_put(struct hashmap *map,
+- struct hashmap_entry *entry);
++ struct hashmap_entry *entry);
+
+ /*
+ * Adds or replaces a hashmap entry contained within @keyvar,
+@@ hashmap.h: struct hashmap_entry *hashmap_put(struct hashmap *map,
+ * Argument explanation is the same as in hashmap_get.
+ */
+ struct hashmap_entry *hashmap_remove(struct hashmap *map,
+- const struct hashmap_entry *key,
+- const void *keydata);
++ const struct hashmap_entry *key,
++ const void *keydata);
+
+ /*
+ * Removes a hashmap entry contained within @keyvar,
+@@ hashmap.h: struct hashmap_entry *hashmap_iter_next(struct hashmap_iter *iter); +
+ /* Initializes the iterator and returns the first entry, if any. */
+ static inline struct hashmap_entry *hashmap_iter_first(struct hashmap *map,
+- struct hashmap_iter *iter)
++ struct hashmap_iter *iter)
+ {
+ hashmap_iter_init(map, iter);
+ return hashmap_iter_next(iter);
3: a686d0758a ! 3: f2718d036d hashmap: allow re-use after hashmap_free()
@@ Commit message
Modify these functions to check for a NULL table and automatically allocate as needed.

- I also thought about creating a HASHMAP_INIT macro to allow initializing
- hashmaps on the stack without calling hashmap_init(), but virtually all
- uses of hashmap specify a usecase-specific equals_function which defeats
- the utility of such a macro.
+ Also add a HASHMAP_INIT(fn, data) macro for initializing hashmaps on the
+ stack without calling hashmap_init().

@@ hashmap.c: struct hashmap_entry *hashmap_remove(struct hashmap *map,
if (!*e)
return NULL;

+
+ ## hashmap.h ##
+@@ hashmap.h: struct hashmap {
+
+ /* hashmap functions */
+
++#define HASHMAP_INIT(fn, data) { .cmpfn = fn, .cmpfn_data = data, \
++ .do_count_items = 1 }
++
+ /*
+ * Initializes a hashmap structure.
+ *
4: 061ab45a9b ! 4: 61f1da3c51 hashmap: introduce a new hashmap_partial_clear()
@@ Commit message
hashmap: introduce a new hashmap_partial_clear()

merge-ort is a heavy user of strmaps, which are built on hashmap.[ch].
- reset_maps() in merge-ort was taking about 12% of overall runtime in my
- testcase involving rebasing 35 patches of linux.git across a big rename.
- reset_maps() was calling hashmap_free() followed by hashmap_init(),
- meaning that not only was it freeing all the memory associated with each
- of the strmaps just to immediately allocate a new array again, it was
- allocating a new array that wasy likely smaller than needed (thus
- resulting in later need to rehash things). The ending size of the map
- table on the previous commit was likely almost perfectly sized for the
- next commit we wanted to pick, and not dropping and reallocating the
- table immediately is a win.
+ clear_or_reinit_internal_opts() in merge-ort was taking about 12% of
+ overall runtime in my testcase involving rebasing 35 patches of
+ linux.git across a big rename. clear_or_reinit_internal_opts() was
+ calling hashmap_free() followed by hashmap_init(), meaning that not only
+ was it freeing all the memory associated with each of the strmaps just
+ to immediately allocate a new array again, it was allocating a new array
+ that was likely smaller than needed (thus resulting in later need to
+ rehash things). The ending size of the map table on the previous commit
+ was likely almost perfectly sized for the next commit we wanted to pick,
+ and not dropping and reallocating the table immediately is a win.

Add some new API to hashmap to clear a hashmap of entries without freeing map->table (and instead only zeroing it out like alloc_table()
@@ hashmap.c: void hashmap_init(struct hashmap *map, hashmap_cmp_fn equals_function

## hashmap.h ##
@@ hashmap.h: void hashmap_init(struct hashmap *map,
- const void *equals_function_data,
- size_t initial_size);
+ const void *equals_function_data,
+ size_t initial_size);

-/* internal function for freeing hashmap */ +/* internal functions for clearing or freeing hashmap */

  -:  ---------- >  5:  861e8d65ae hashmap: provide deallocation function names
  5:  5c7507f55b !  6:  448d3b219f strmap: new utility functions
     @@ Commit message
          taken directly from Peff's proposal at
          https://lore.kernel.org/git/[email protected]/
      
     -    A couple of items of note:
     -
     -      * Similar to string-list, I have a strdup_strings setting.  However,
     -        unlike string-list, strmap_init() does not take a parameter for this
     -        setting and instead automatically sets it to 1; callers who want to
     -        control this detail need to instead call strmap_ocd_init().
     -
     -      * I do not have a STRMAP_INIT macro.  I could possibly add one, but
     -          #define STRMAP_INIT { { NULL, cmp_str_entry, NULL, 0, 0, 0, 0, 0 }, 1 }
     -        feels a bit unwieldy and possibly error-prone in terms of future
     -        expansion of the hashmap struct.  The fact that cmp_str_entry needs to
     -        be in there prevents us from passing all zeros for the hashmap, and makes
     -        me worry that STRMAP_INIT would just be more trouble than it is worth.
     +    Note that similar string-list, I have a strdup_strings setting.
     +    However, unlike string-list, strmap_init() does not take a parameter for
     +    this setting and instead automatically sets it to 1; callers who want to
     +    control this detail need to instead call strmap_init_with_options().
     +    (Future patches will add additional parameters to
     +    strmap_init_with_options()).
      
          Signed-off-by: Elijah Newren <[email protected]>
      
     @@ strmap.c (new)
      +#include "git-compat-util.h"
      +#include "strmap.h"
      +
     -+static int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
     -+			    const struct hashmap_entry *entry1,
     -+			    const struct hashmap_entry *entry2,
     -+			    const void *keydata)
     ++int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
     ++		     const struct hashmap_entry *entry1,
     ++		     const struct hashmap_entry *entry2,
     ++		     const void *keydata)
      +{
      +	const struct strmap_entry *e1, *e2;
      +
     @@ strmap.c (new)
      +
      +void strmap_init(struct strmap *map)
      +{
     -+	strmap_ocd_init(map, 1);
     ++	strmap_init_with_options(map, 1);
      +}
      +
     -+void strmap_ocd_init(struct strmap *map,
     -+		     int strdup_strings)
     ++void strmap_init_with_options(struct strmap *map,
     ++			      int strdup_strings)
      +{
      +	hashmap_init(&map->map, cmp_strmap_entry, NULL, 0);
      +	map->strdup_strings = strdup_strings;
      +}
      +
     -+static void strmap_free_entries_(struct strmap *map, int free_util)
     ++static void strmap_free_entries_(struct strmap *map, int free_values)
      +{
      +	struct hashmap_iter iter;
      +	struct strmap_entry *e;
     @@ strmap.c (new)
      +	 * to make some call into the hashmap API to do that.
      +	 */
      +	hashmap_for_each_entry(&map->map, &iter, e, ent) {
     -+		if (free_util)
     ++		if (free_values)
      +			free(e->value);
      +		if (map->strdup_strings)
      +			free((char*)e->key);
     @@ strmap.c (new)
      +	}
      +}
      +
     -+void strmap_clear(struct strmap *map, int free_util)
     ++void strmap_clear(struct strmap *map, int free_values)
      +{
     -+	strmap_free_entries_(map, free_util);
     -+	hashmap_free(&map->map);
     ++	strmap_free_entries_(map, free_values);
     ++	hashmap_clear(&map->map);
      +}
      +
      +void *strmap_put(struct strmap *map, const char *str, void *data)
     @@ strmap.c (new)
      +		old = entry->value;
      +		entry->value = data;
      +	} else {
     -+		/*
     -+		 * We won't modify entry->key so it really should be const.
     -+		 */
      +		const char *key = str;
      +
      +		entry = xmalloc(sizeof(*entry));
     @@ strmap.h (new)
      +	void *value;
      +};
      +
     ++int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
     ++		     const struct hashmap_entry *entry1,
     ++		     const struct hashmap_entry *entry2,
     ++		     const void *keydata);
     ++
     ++#define STRMAP_INIT { \
     ++			.map = HASHMAP_INIT(cmp_strmap_entry, NULL),  \
     ++			.strdup_strings = 1,                          \
     ++		    }
     ++
      +/*
      + * Initialize the members of the strmap.  Any keys added to the strmap will
      + * be strdup'ed with their memory managed by the strmap.
     @@ strmap.h (new)
      +/*
      + * Same as strmap_init, but for those who want to control the memory management
      + * carefully instead of using the default of strdup_strings=1.
     -+ * (OCD = Obsessive Compulsive Disorder, a joke that those who use this function
     -+ * are obsessing over minor details.)
      + */
     -+void strmap_ocd_init(struct strmap *map,
     -+		     int strdup_strings);
     ++void strmap_init_with_options(struct strmap *map,
     ++			      int strdup_strings);
      +
      +/*
      + * Remove all entries from the map, releasing any allocated resources.
  6:  61b5bf1110 !  7:  42633b8d03 strmap: add more utility functions
     @@ Commit message
          strmap: add more utility functions
      
          This adds a number of additional convienence functions I want/need:
     -      * strmap_empty()
            * strmap_get_size()
     +      * strmap_empty()
            * strmap_remove()
            * strmap_for_each_entry()
            * strmap_get_entry()
     @@ strmap.c: int strmap_contains(struct strmap *map, const char *str)
       	return find_strmap_entry(map, str) != NULL;
       }
      +
     -+void strmap_remove(struct strmap *map, const char *str, int free_util)
     ++void strmap_remove(struct strmap *map, const char *str, int free_value)
      +{
      +	struct strmap_entry entry, *ret;
      +	hashmap_entry_init(&entry.ent, strhash(str));
     @@ strmap.c: int strmap_contains(struct strmap *map, const char *str)
      +	ret = hashmap_remove_entry(&map->map, &entry, ent, NULL);
      +	if (!ret)
      +		return;
     -+	if (free_util)
     ++	if (free_value)
      +		free(ret->value);
      +	if (map->strdup_strings)
      +		free((char*)ret->key);
     @@ strmap.h: void *strmap_get(struct strmap *map, const char *str);
      +void strmap_remove(struct strmap *map, const char *str, int free_value);
      +
      +/*
     -+ * Return whether the strmap is empty.
     ++ * Return how many entries the strmap has.
      + */
     -+static inline int strmap_empty(struct strmap *map)
     ++static inline unsigned int strmap_get_size(struct strmap *map)
      +{
     -+	return hashmap_get_size(&map->map) == 0;
     ++	return hashmap_get_size(&map->map);
      +}
      +
      +/*
     -+ * Return how many entries the strmap has.
     ++ * Return whether the strmap is empty.
      + */
     -+static inline unsigned int strmap_get_size(struct strmap *map)
     ++static inline int strmap_empty(struct strmap *map)
      +{
     -+	return hashmap_get_size(&map->map);
     ++	return strmap_get_size(map) == 0;
      +}
      +
      +/*
      + * iterate through @map using @iter, @var is a pointer to a type strmap_entry
      + */
      +#define strmap_for_each_entry(mystrmap, iter, var)	\
     -+	for (var = hashmap_iter_first_entry_offset(&(mystrmap)->map, iter, \
     -+						   OFFSETOF_VAR(var, ent)); \
     ++	for (var = hashmap_iter_first_entry_offset(&(mystrmap)->map, iter, 0); \
      +		var; \
     -+		var = hashmap_iter_next_entry_offset(iter, \
     -+						     OFFSETOF_VAR(var, ent)))
     ++		var = hashmap_iter_next_entry_offset(iter, 0))
      +
       #endif /* STRMAP_H */

7: 2ebce0c5d8 ! 8: ea942eb803 strmap: enable faster clearing and reusing of strmaps
@@ Commit message
Introduce strmap_partial_clear() to take advantage of this type of situation; it will act similar to strmap_clear() except that map->table's entries are zeroed instead of map->table being free'd.
- Making use of this function reduced the cost of reset_maps() by about
- 20% in mert-ort, and dropped the overall runtime of my rebase testcase
- by just under 2%.
+ Making use of this function reduced the cost of
+ clear_or_reinit_internal_opts() by about 20% in mert-ort, and dropped
+ the overall runtime of my rebase testcase by just under 2%.

## strmap.c ##
-@@ strmap.c: void strmap_clear(struct strmap *map, int free_util)
- hashmap_free(&map->map);
+@@ strmap.c: void strmap_clear(struct strmap *map, int free_values)
+ hashmap_clear(&map->map);
}

-+void strmap_partial_clear(struct strmap *map, int free_util) ++void strmap_partial_clear(struct strmap *map, int free_values)
+{
-+ strmap_free_entries_(map, free_util);
++ strmap_free_entries_(map, free_values);
+ hashmap_partial_clear(&map->map);
+}
+
@@ strmap.c: void strmap_clear(struct strmap *map, int free_util)
struct strmap_entry *entry = find_strmap_entry(map, str);

## strmap.h ##
-@@ strmap.h: void strmap_ocd_init(struct strmap *map, +@@ strmap.h: void strmap_init_with_options(struct strmap *map,
*/
void strmap_clear(struct strmap *map, int free_values);

8: cc8d702f98 ! 9: c1d2172171 strmap: add functions facilitating use as a string->int map

     @@ Commit message
          Signed-off-by: Elijah Newren <[email protected]>
      
       ## strmap.c ##
     -@@ strmap.c: void strmap_remove(struct strmap *map, const char *str, int free_util)
     +@@ strmap.c: void strmap_remove(struct strmap *map, const char *str, int free_value)
       		free((char*)ret->key);
       	free(ret);
       }
     @@ strmap.c: void strmap_remove(struct strmap *map, const char *str, int free_util)
      +		*whence += amt;
      +	}
      +	else
     -+		strintmap_set(map, str, amt);
     ++		strintmap_set(map, str, map->default_value + amt);
      +}
      
       ## strmap.h ##
     -@@ strmap.h: static inline unsigned int strmap_get_size(struct strmap *map)
     - 		var = hashmap_iter_next_entry_offset(iter, \
     - 						     OFFSETOF_VAR(var, ent)))
     +@@ strmap.h: int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
     + 			.map = HASHMAP_INIT(cmp_strmap_entry, NULL),  \
     + 			.strdup_strings = 1,                          \
     + 		    }
     ++#define STRINTMAP_INIT { \
     ++			.map.map = HASHMAP_INIT(cmp_strmap_entry, NULL),  \
     ++			.map.strdup_strings = 1,                          \
     ++			.default_value = 0,                               \
     ++		    }
     + 
     + /*
     +  * Initialize the members of the strmap.  Any keys added to the strmap will
     +@@ strmap.h: static inline int strmap_empty(struct strmap *map)
     + 		var; \
     + 		var = hashmap_iter_next_entry_offset(iter, 0))
       
      +
      +/*
     @@ strmap.h: static inline unsigned int strmap_get_size(struct strmap *map)
      +
      +struct strintmap {
      +	struct strmap map;
     ++	int default_value;
      +};
      +
      +#define strintmap_for_each_entry(mystrmap, iter, var)	\
      +	strmap_for_each_entry(&(mystrmap)->map, iter, var)
      +
     -+static inline void strintmap_init(struct strintmap *map)
     ++static inline void strintmap_init(struct strintmap *map, int default_value)
      +{
      +	strmap_init(&map->map);
     ++	map->default_value = default_value;
      +}
      +
     -+static inline void strintmap_ocd_init(struct strintmap *map,
     -+				      int strdup_strings)
     ++static inline void strintmap_init_with_options(struct strintmap *map,
     ++					       int default_value,
     ++					       int strdup_strings)
      +{
     -+	strmap_ocd_init(&map->map, strdup_strings);
     ++	strmap_init_with_options(&map->map, strdup_strings);
     ++	map->default_value = default_value;
      +}
      +
      +static inline void strintmap_clear(struct strintmap *map)
     @@ strmap.h: static inline unsigned int strmap_get_size(struct strmap *map)
      +	return strmap_get_size(&map->map);
      +}
      +
     -+static inline int strintmap_get(struct strintmap *map, const char *str,
     -+				int default_value)
     ++/*
     ++ * Returns the value for str in the map.  If str isn't found in the map,
     ++ * the map's default_value is returned.
     ++ */
     ++static inline int strintmap_get(struct strintmap *map, const char *str)
      +{
      +	struct strmap_entry *result = strmap_get_entry(&map->map, str);
      +	if (!result)
     -+		return default_value;
     ++		return map->default_value;
      +	return (intptr_t)result->value;
      +}
      +
     @@ strmap.h: static inline unsigned int strmap_get_size(struct strmap *map)
      +	strmap_put(&map->map, str, (void *)v);
      +}
      +
     ++/*
     ++ * Increment the value for str by amt.  If str isn't in the map, add it and
     ++ * set its value to default_value + amt.
     ++ */
      +void strintmap_incr(struct strintmap *map, const char *str, intptr_t amt);
      +
       #endif /* STRMAP_H */
  9:  490d3a42ad ! 10:  0f57735f5e strmap: add a strset sub-type
     @@ Commit message
      
          The difference in usage also results in some differences in API: a few
          things that aren't necessary or meaningful are dropped (namely, the
     -    free_util argument to *_clear(), and the *_get() function), and
     +    free_values argument to *_clear(), and the *_get() function), and
          strset_add() is chosen as the API instead of strset_put().
      
     +    Finally, shortlog already had a more minimal strset API; so this adds a
     +    strset_check_and_add() function for its benefit to allow it to switch
     +    over to this strset implementation.
     +
          Signed-off-by: Elijah Newren <[email protected]>
      
     + ## strmap.c ##
     +@@ strmap.c: void strintmap_incr(struct strintmap *map, const char *str, intptr_t amt)
     + 	else
     + 		strintmap_set(map, str, map->default_value + amt);
     + }
     ++
     ++int strset_check_and_add(struct strset *set, const char *str)
     ++{
     ++	if (strset_contains(set, str))
     ++		return 1;
     ++	strset_add(set, str);
     ++	return 0;
     ++}
     +
       ## strmap.h ##
     -@@ strmap.h: static inline void strintmap_set(struct strintmap *map, const char *str,
     +@@ strmap.h: int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
     + 			.map.strdup_strings = 1,                          \
     + 			.default_value = 0,                               \
     + 		    }
     ++#define STRSET_INIT { \
     ++			.map.map = HASHMAP_INIT(cmp_strmap_entry, NULL),  \
     ++			.map.strdup_strings = 1,                          \
     ++		    }
       
     + /*
     +  * Initialize the members of the strmap.  Any keys added to the strmap will
     +@@ strmap.h: static inline void strintmap_set(struct strintmap *map, const char *str,
     +  */
       void strintmap_incr(struct strintmap *map, const char *str, intptr_t amt);
       
      +/*
     @@ strmap.h: static inline void strintmap_set(struct strintmap *map, const char *st
      +	strmap_init(&set->map);
      +}
      +
     -+static inline void strset_ocd_init(struct strset *set,
     -+				   int strdup_strings)
     ++static inline void strset_init_with_options(struct strset *set,
     ++					    int strdup_strings)
      +{
     -+	strmap_ocd_init(&set->map, strdup_strings);
     ++	strmap_init_with_options(&set->map, strdup_strings);
      +}
      +
      +static inline void strset_clear(struct strset *set)
     @@ strmap.h: static inline void strintmap_set(struct strintmap *map, const char *st
      +{
      +	strmap_put(&set->map, str, NULL);
      +}
     ++
     ++/* Returns 1 if str already in set.  Otherwise adds str to set and returns 0 */
     ++int strset_check_and_add(struct strset *set, const char *str);
      +
       #endif /* STRMAP_H */

10: eca4f1ddba ! 11: 980537e877 strmap: enable allocations to come from a mem_pool
@@ Commit message

For heavy users of strmaps, allowing the keys and entries to be allocated from a memory pool can provide significant overhead savings.
- Add an option to strmap_ocd_init() to specify a memory pool.
+ Add an option to strmap_init_with_options() to specify a memory pool.

@@ strmap.c
#include "strmap.h"
+#include "mem-pool.h"

- static int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
- const struct hashmap_entry *entry1,
+ int cmp_strmap_entry(const void *hashmap_cmp_fn_data,
+ const struct hashmap_entry *entry1,
@@ strmap.c: static struct strmap_entry *find_strmap_entry(struct strmap *map,

void strmap_init(struct strmap *map)
{
-- strmap_ocd_init(map, 1);
-+ strmap_ocd_init(map, NULL, 1);
+- strmap_init_with_options(map, 1);
++ strmap_init_with_options(map, NULL, 1);
}

- void strmap_ocd_init(struct strmap *map,
-+ struct mem_pool *pool,
- int strdup_strings)
+ void strmap_init_with_options(struct strmap *map,
++ struct mem_pool *pool,
+ int strdup_strings)
{
hashmap_init(&map->map, cmp_strmap_entry, NULL, 0);
+ map->pool = pool;
map->strdup_strings = strdup_strings;
}

-@@ strmap.c: static void strmap_free_entries_(struct strmap *map, int free_util) +@@ strmap.c: static void strmap_free_entries_(struct strmap *map, int free_values)
if (!map)
return;

-+ if (!free_util && map->pool)
++ if (!free_values && map->pool)
+ /* Memory other than util is owned by and freed with the pool */
+ return;
+
/*
* We need to iterate over the hashmap entries and free
* e->key and e->value ourselves; hashmap has no API to
-@@ strmap.c: static void strmap_free_entries_(struct strmap *map, int free_util) +@@ strmap.c: static void strmap_free_entries_(struct strmap *map, int free_values)
hashmap_for_each_entry(&map->map, &iter, e, ent) {
- if (free_util)
+ if (free_values)
free(e->value);
- if (map->strdup_strings)
- free((char*)e->key);
@@ strmap.c: static void strmap_free_entries_(struct strmap *map, int free_util)
}

@@ strmap.c: void *strmap_put(struct strmap *map, const char *str, void *data)
- */
+ } else {
const char *key = str;

- entry = xmalloc(sizeof(*entry));
@@ strmap.c: void *strmap_put(struct strmap *map, const char *str, void *data)
entry->key = key;
entry->value = data;
hashmap_add(&map->map, &entry->ent);
-@@ strmap.c: void strmap_remove(struct strmap *map, const char *str, int free_util) +@@ strmap.c: void strmap_remove(struct strmap *map, const char *str, int free_value)
return;
- if (free_util)
+ if (free_value)
free(ret->value);
- if (map->strdup_strings)
- free((char*)ret->key);
@@ strmap.h: void strmap_init(struct strmap *map);
* Same as strmap_init, but for those who want to control the memory management
- * carefully instead of using the default of strdup_strings=1.
+ * carefully instead of using the default of strdup_strings=1 and pool=NULL.
- * (OCD = Obsessive Compulsive Disorder, a joke that those who use this function
- * are obsessing over minor details.)
*/
- void strmap_ocd_init(struct strmap *map,
-+ struct mem_pool *pool,
- int strdup_strings);
+ void strmap_init_with_options(struct strmap *map,
++ struct mem_pool *pool,
+ int strdup_strings);

/*
-@@ strmap.h: static inline void strintmap_init(struct strintmap *map)
- }
+@@ strmap.h: static inline void strintmap_init(struct strintmap *map, int default_value)

- static inline void strintmap_ocd_init(struct strintmap *map,
-+ struct mem_pool *pool,
- int strdup_strings)
+ static inline void strintmap_init_with_options(struct strintmap *map,
+ int default_value,
++ struct mem_pool *pool,
+ int strdup_strings)
{
-- strmap_ocd_init(&map->map, strdup_strings);
-+ strmap_ocd_init(&map->map, pool, strdup_strings);
+- strmap_init_with_options(&map->map, strdup_strings);
++ strmap_init_with_options(&map->map, pool, strdup_strings);
+ map->default_value = default_value;
}

- static inline void strintmap_clear(struct strintmap *map) @@ strmap.h: static inline void strset_init(struct strset *set) }

- static inline void strset_ocd_init(struct strset *set,
-+ struct mem_pool *pool,
- int strdup_strings)
+ static inline void strset_init_with_options(struct strset *set,
++ struct mem_pool *pool,
+ int strdup_strings)
{
-- strmap_ocd_init(&set->map, strdup_strings);
-+ strmap_ocd_init(&set->map, pool, strdup_strings);
+- strmap_init_with_options(&set->map, strdup_strings);
++ strmap_init_with_options(&set->map, pool, strdup_strings);
}

static inline void strset_clear(struct strset *set)

  -:  ---------- > 12:  7f93cbb525 strmap: take advantage of FLEXPTR_ALLOC_STR when relevant
  -:  ---------- > 13:  5f41fc63e5 Use new HASHMAP_INIT macro to simplify hashmap initialization

gitgitgadget

From: Elijah Newren <[email protected]>

The existence of hashmap_free() and hashmap_free_entries() confused me, and the docs weren't clear enough. We are dealing with a map table, entries in that table, and possibly also things each of those entries point to. I had to consult other source code examples and the implementation. Add a brief note to clarify the differences. This will become even more important once we introduce a new hashmap_partial_clear() function which will add the question of whether the table itself has been freed.

---
 hashmap.h | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

index b011b394fe..2994dc7a9c 100644
@@ -236,13 +236,40 @@ void hashmap_init(struct hashmap *map,
 void hashmap_free_(struct hashmap *map, ssize_t offset);
 
 /*
- * Frees a hashmap structure and allocated memory, leaves entries undisturbed
+ * Frees a hashmap structure and allocated memory for the table, but does not
+ * free the entries nor anything they point to.
+ *
+ * Usage note:
+ *
+ * Many callers will need to iterate over all entries and free the data each
+ * entry points to; in such a case, they can free the entry itself while at it.
+ * Thus, you might see:
+ *
+ *    hashmap_for_each_entry(map, hashmap_iter, e, hashmap_entry_name) {
+ *      free(e->somefield);
+ *      free(e);
+ *    }
+ *    hashmap_free(map);
+ *
+ * instead of
+ *
+ *    hashmap_for_each_entry(map, hashmap_iter, e, hashmap_entry_name) {
+ *      free(e->somefield);
+ *    }
+ *    hashmap_free_entries(map, struct my_entry_struct, hashmap_entry_name);
+ *
+ * to avoid the implicit extra loop over the entries.  However, if there are
+ * no special fields in your entry that need to be freed beyond the entry
+ * itself, it is probably simpler to avoid the explicit loop and just call
+ * hashmap_free_entries().
  */
 #define hashmap_free(map) hashmap_free_(map, -1)
 
 /*
  * Frees @map and all entries.  @type is the struct type of the entry
- * where @member is the hashmap_entry struct used to associate with @map
+ * where @member is the hashmap_entry struct used to associate with @map.
+ *
+ * See usage note above hashmap_free().
  */
 #define hashmap_free_entries(map, type, member) \
 	hashmap_free_(map, offsetof(type, member));

gitgitgadget

From: Elijah Newren <[email protected]>

No actual code changes; just whitespace adjustments.

---
 hashmap.c | 17 +++++++++--------
 hashmap.h | 22 +++++++++++-----------
 2 files changed, 20 insertions(+), 19 deletions(-)

index 09813e1a46..e44d8a3e85 100644
@@ -92,8 +92,9 @@ static void alloc_table(struct hashmap *map, unsigned int size)
 }
 
 static inline int entry_equals(const struct hashmap *map,
-		const struct hashmap_entry *e1, const struct hashmap_entry *e2,
-		const void *keydata)
+			       const struct hashmap_entry *e1,
+			       const struct hashmap_entry *e2,
+			       const void *keydata)
 {
 	return (e1 == e2) ||
 	       (e1->hash == e2->hash &&

@@ -101,7 +102,7 @@ static inline int entry_equals(const struct hashmap *map,
 }
 
 static inline unsigned int bucket(const struct hashmap *map,
-		const struct hashmap_entry *key)
+				  const struct hashmap_entry *key)
 {
 	return key->hash & (map->tablesize - 1);
 }

@@ -148,7 +149,7 @@ static int always_equal(const void *unused_cmp_data,
 }
 
 void hashmap_init(struct hashmap *map, hashmap_cmp_fn equals_function,
-		const void *cmpfn_data, size_t initial_size)
+		  const void *cmpfn_data, size_t initial_size)
 {
 	unsigned int size = HASHMAP_INITIAL_SIZE;
 

@@ -199,7 +200,7 @@ struct hashmap_entry *hashmap_get(const struct hashmap *map,
 }
 
 struct hashmap_entry *hashmap_get_next(const struct hashmap *map,
-			const struct hashmap_entry *entry)
+				       const struct hashmap_entry *entry)
 {
 	struct hashmap_entry *e = entry->next;
 	for (; e; e = e->next)

@@ -225,8 +226,8 @@ void hashmap_add(struct hashmap *map, struct hashmap_entry *entry)
 }
 
 struct hashmap_entry *hashmap_remove(struct hashmap *map,
-					const struct hashmap_entry *key,
-					const void *keydata)
+				     const struct hashmap_entry *key,
+				     const void *keydata)
 {
 	struct hashmap_entry *old;
 	struct hashmap_entry **e = find_entry_ptr(map, key, keydata);

@@ -249,7 +250,7 @@ struct hashmap_entry *hashmap_remove(struct hashmap *map,
 }
 
 struct hashmap_entry *hashmap_put(struct hashmap *map,
-				struct hashmap_entry *entry)
+				  struct hashmap_entry *entry)
 {
 	struct hashmap_entry *old = hashmap_remove(map, entry, NULL);
 	hashmap_add(map, entry);

index 2994dc7a9c..904f61d6e1 100644
@@ -228,9 +228,9 @@ struct hashmap {
  * prevent expensive resizing. If 0, the table is dynamically resized.
  */
 void hashmap_init(struct hashmap *map,
-			 hashmap_cmp_fn equals_function,
-			 const void *equals_function_data,
-			 size_t initial_size);
+		  hashmap_cmp_fn equals_function,
+		  const void *equals_function_data,
+		  size_t initial_size);
 
 /* internal function for freeing hashmap */
 void hashmap_free_(struct hashmap *map, ssize_t offset);

@@ -288,7 +288,7 @@ void hashmap_free_(struct hashmap *map, ssize_t offset);
  * and if it is on stack, you can just let it go out of scope).
  */
 static inline void hashmap_entry_init(struct hashmap_entry *e,
-					unsigned int hash)
+				      unsigned int hash)
 {
 	e->hash = hash;
 	e->next = NULL;