My general comments about the active defrag in relation to this PR:

The basic idea behind defrag is that the allocations for the dataset might become very fragmented over time and at the same time the dataset is organized through a single dictionary. So it's easy to defrag it.
In my opinion not all dictionaries need to be defraged, do we defrag the Users Rax?

If we decide to defrag everything then at some point we'll probably run into the following:

1. The code will become spaghetti because defrag.c will need to know the internals of everything.
2. We'll have bugs because someone eventually will reference a pointer in some other place not thinking about defrag and then the pointer will get defragged and we'll access deallocated pointers.

We should try to keep defrag to dataset because it's by definition accessed only from a single location and tends to have more "public" interfaces for its data structures.

Alternatively we can simply fix the existing code in the following way:
make defrag.c aware of luaScript struct and then add another DEFRAG_SDS_DICT_VAL_LUA_SCRIPT and handle it in activeDefragSdsDict().

i'm not sure defrag is only about data set. it's about anything that can grow large and remain for long!

for instance, there's no point in defraging users, since they're not expected to grow much, and are also kinda static, and there's no point in defragging output buffers, since they're temporary.

However, Eval script remain for long, and in some cases can be unintentionally bloated.
I've seen cases with many thousands of scripts.
note that it's enough for one small allocation to hold a whole run hostage and prevent defragging.
i.e. maybe the dictEntry for that dict will do more damage than the script code itself.

Functions may be less of a problem, since i think they'll tend to be more static, and won't be unintentionally bloated.
however, by your definition, they ARE part of the data.

daily CI on the new test: https://github.com/redis/redis/actions/runs/1830886427