what if the freed hole is between 2 anon vma entries (curr_min_addr will fall down to the higher entry->end right?), however the hole won't be reused.
I used the test code mentioned earlier to verify your patch, still I can see anon_loc growing and memory footprint increasing.

In D39845#907052, @kib wrote:

We cannot provide the minimal VA spread with ASLR, after all this is the point of the 'R' in it. To glue vm_map_entries and underlying objects to avoid their proliferation is the goal of clustering.

My thought is upward migration of map->anon_loc could lead problem in some condition.
below test code can demonstrate malloced address still shift to higher address due to anon_loc updating, forcing jemalloc to eat more memory to store metadata.

introduce vm.anon_low_pref option to optimize cluster anon behavior.

By setting vm.cluster_anon=1, the clustering and updating of anon_loc will not occur during the test, preventing the occurrence of the jemalloc leak issue.
Which means this change is specifically targeting scenarios with vm.cluster_anon=2. So is it not recommend to use cluster_anon=2 in practice? we tried this setting to suppress vma fragment.

In D39743#905866, @kib wrote:

Is the patch reversed? Also, please generate full context when uploading a patch to the FreeBSD phabricator (diff -U 999999999).

If the patch is reversed, I believe that it is an optimization for very specific usage. For instance, if you change your demostration program to increment the malloc'ed size by PAGE_SIZE for each iteration, VSS would start growing the same as without the patch. Really it just disables anon clustering.

That said, I would not object against a knob to disable updating anon_loc, if it helps for some specific heavy loads.