Sverker Eriksson

Thanks, @lemenkov I rebased your branch for merge to maint and OTP-25.1.

Some words of warning. Even though the strict ordering we internally use for small map keys is not defined as an iteration order, it does "leak out" as the defined...

I was wrong, this PR does actually break map comparison: ``` 1> {a1,a2,a3}. {a1,a2,a3} 2> a1 < a2. true 3> a2 < a3. true 4> #{a1 => v, true =>...

It will be slower, but can actually be done O(n) with the same algorithm as for hashmaps where the keys are ordered by hash value. https://github.com/erlang/otp/blob/master/erts/emulator/beam/utils.c#L1794 It's more comparisons and...

OTP Technical Board says: We want this to boosts performance of frequent small map atom key comparisons at the expense of much less common ordering of entire maps. `maps:to_list` and...

Amendment: It's probably enough to only order top level atoms by index, like this PR does. That will make the code less complex I think.

In "Thread 5 (LWP 1033)", the 5 is just a number assigned by gdb (I think). The 1033 is the OS thread identifier that should be stored as __data.__owner in...

It would be interesting to see the content of the DistEntry with the failing mutex: ``` (gdb) frame 12 (gdb) print *dep ``` and also the binary containing it: ```...

What kind of Erlang node distribution are you running? Default TCP, TLS or something else?

What OTP version is this?