Hi Evan,
> - We weren't doing anything with the emem slab that couldn't be done with glib slices.
Right now no, but there was implementation of sl_free_all().
> - Glib slices are much cache-friendlier
Do you have any benchmarks/ cachegrind output to proof it?
It's quite normal use to iterate over nodes, in old code we tried to allocate
all proto_tree nodes in one page. I doubt if glib slice allocator can do better.
If you're talking about something else please specify.
> - multi-threading friendly
True, but I have patch to fix it (when needed).
Generally we don't need it to be truly MT-friendly, just make single slab for single edt.
> Allows glib to actually return slices to the OS on occasion. The emem
> slab would hold onto its memory forever which resulted in a great deal of
> wasted memory after closing a large file.
False, it was currently used for fvalue_t, item_label_t, proto_node, which
generally are allocated for one or two frames
(generally number of currently running epan_disset with tree).
Generally I'm fine with removing this code, but I dislike when someone
criticize my code without proofs :P
(It was me, who changed some SLAB_* use to sl_ in r37030)
Speaking of which there's still SLAB_ code in packet-tcp.c.