builtin: fix map.clear() not resetting map's metas and keys blocks (fix #22139)

[spytheman]

Fix #22139 .

[ka-weihe]

Hi @spytheman 😄

I think you also have to clear/free the memory of the denseArray. I think that right now it will just leak.

[spytheman]

@ka-weihe thanks for reviewing.

I think, that the explicit goal of that .clear() method, rather than just m = {}, was to not free the main memory blocks, used for the keys and values, so that they would be available right away, for reuse, in subsequent m[key]=val operations.

Is there a mechanism, where the old blocks would just leak (rather than being reused), and new ones will be allocated instead, when the user does this for example:

mut m := map[int]int{}
m[123] = 456
m[789] = 321
m.clear()
m[1] = 10
m[2] = 20

[ka-weihe]

Is there a mechanism, where the old blocks would just leak (rather than being reused), and new ones will be allocated instead, when the user does this for example:

mut m := map[int]int{}
m[123] = 456
m[789] = 321
m.clear()
m[1] = 10
m[2] = 20

Hmm, after looking at the code again, I think it might actually be fine, but it would be interesting to run it in a loop and see if the memory usage keeps increasing. I don't think it will, but it's a good test.

[JalonSolov]

Yes, the .clear() was to mark the map as "empty", but not change the amount of memory already allocated. Too much memory churn that way.

You can always do m = map[int]int{} again to completely wipe it, free the memory, and start over. Or just m = {} if that works.

[spytheman]

Hmm, after looking at the code again, I think it might actually be fine, but it would be interesting to run it in a loop and see if the memory usage keeps increasing. I don't think it will, but it's a good test.

I've added cmd/tools/bench/map_clear.v and cmd/tools/bench/map_clear_runner.vsh to make it easier to test that, for different options and iteration counts.
The results is that there is no increase in the memory usage, for me on Ubuntu 20.04:

I've tested with these commands on my latest commit, if someone else wants to check:
FLAGS='' cmd/tools/bench/map_clear_runner.vsh 1_000_000 100_000_000 10_000_000
FLAGS='-gc none' cmd/tools/bench/map_clear_runner.vsh 1_000_000 100_000_000 10_000_000
FLAGS='-prod -cc clang' cmd/tools/bench/map_clear_runner.vsh
FLAGS='-gc none -prod -cc clang' cmd/tools/bench/map_clear_runner.vsh

(you will need the latest commit 63a51ff)

[spytheman]

Here is a heaptrack view after running:
v -gc none -cc gcc -cg -keepc cmd/tools/bench/map_clear.v
heaptrack cmd/tools/bench/map_clear 50_000_000 (the run takes ~4.6 seconds)
heaptrack --analyze "/space/v/oo/heaptrack.map_clear.87529.zst"

[spytheman]

And the same, but after a longer run heaptrack cmd/tools/bench/map_clear 99_000_000 (takes 8.8s):