Avoid free() on quit

[mrnoname1000]

As far as I can tell without debugging, mpv decides to free all the malloc'd memory before quitting. This wastes CPU cycles since it would happen anyway when the process exits. I have had mpv take several minutes to quit because most of its memory was inactive and written to swap, which it has to read back to free. The desired behavior can be observed with a kill -9 <mpv pid> as even if mpv has gigabytes in swap, it will still terminate immediately.

It still might be necessary to release some resources before quit, but free() can be safely omitted. I'm not familiar with the codebase but maybe a global variable in the mpv executable would be fine to track if free() is necessary. I don't imagine this would apply to libmpv unless it can call exit() as well.

Expected behavior of the wanted feature

mpv quits immediately with minimal calls to free().

Alternative behavior of the wanted feature

Currently? mpv frees all blocks received by malloc/calloc then quits.

[CounterPillow]

Won't this break every single memleak tracking tool?

[Dudemanguy]

There's basically no sane way to attempt something like this even if we wanted to.

[N-R-K]

Won't this break every single memleak tracking tool?

LeakSanitizer is smart enough to not flag "reachable" pointers as leak. But "dumb" leak checkers like MPV_LEAK_REPORT will be broken. But leak checking is useful for debugging/development, it's possible to omit shutdown free-s on "release" builds only.

This wastes CPU cycles since it would happen anyway when the process exits.

Technically, I agree. And this can become visibly slow if the program has to chase lots of pointers trying to free a list or tree like structure.

(Ahem, precisely what talloc does. And the problem is made worse if your system malloc is slow since talloc does it's bookkeeping on top of system malloc.)

before quit free() can be safely omitted.

Unfortunately though, I suspect such a change won't be trivial - even though it technically makes sense to do.

I have had mpv take several minutes to quit

No clue which libc you're using - but I wonder if LD_PRELOAD-ing a "fast" malloc such as mimalloc or tcmalloc would help or not. (Probably not if the bottleneck is pointer chases in mpv/talloc, but it's still worth a try, I think).

[mrnoname1000]

@N-R-K
You hit the nail on the head! Usually if a program does this it's controlled by a compile-time macro or a run-time parameter. Here's some pseudo C that shows my thinking:

int mpv_exiting = 0;

void mpv_free(void *p) {
#if MPV_CLI && MPV_RELEASE_BUILD
  if (mpv_exiting) return;
#endif
  free(p);
}

void mpv_exit(int code) {
  mpv_exiting = 1;
  release_resources();
  exit(code);
}

No clue which libc you're using

I'm using glibc which uses tcmalloc IIRC. I could give another malloc a shot but it will be a while before I get it installed and play with mpv enough for it to swap. However musl is accessible to me so I could give that a shot anytime.