SV Arenas have duplicate sized pool slots #22665
Comments
It's been in the middle of my ideas list but has never made it to the top. I do think it's worth doing this, and possibly looking to see if increasing the pool size from 4k to e.g. 8k would give less wastage. I'm also curious to see if all bodies were allocated from arenas, whether compilers would pick up on that and automatically optimise away the existing "return to arena or Safefree" branches. |
The generate_uudmap.exe cleanup branch, one reason for it was, I wanted a test, and learn the actual boundaries of the OS/libc/vendor malloc, vs P5's current amateur guesses derived from the generic 4096 x86 page. Its impl specific ub, where malloc() keeps its book keeping. The traditional 2 pointers right before your ptr??? does the malloc steal 1-7 bytes below "power of 2" at the end of your alloc??? Was the OS designer bold and daring, and there IS NO HEADER, that malloc uses a red black tree???? P5 core also has 2 or 3 different malloc on malloc systems right now one is Win32 specific threads specific, other is -DDEBUGGING specific, and 3rd is P5 Configure decides OS malloc is garbage and totally replaces it. While there is some attempt at doing all the math, to correctly subtract P5 malloc wrapper headers vs build options vs our #define GOODSIZE 4096, the offsets and constants were picked decades ago, and there is no CI code to test if all those guesses and constants are correct. Its very rare a core dev, will use a C debugger and step into the OS malloc code, or use OS VM analystic tools. A single +1 or -1 mistake in our math for GOODSIZE can perm waste 1-15 or 1-31 bytes over and over. |
Description
SV Body arena roots are duplicative and redundant.
SVt_PVNV and SVt_PVHV are identical.
SVt_INVLIST, SVt_PVAV, SVt_PVOBJ are identical.
SVt_PVMG and SVt_PVGV are identical.
SVt_PVCV and SVt_PVFM are identical.
SVt_PVFM is marked "NOARENA" yet would fit exactly into SVt_PVCV's pool.
Why arent these free memory pools sorted and deduped by size? It
would make some room for struct MG and struct GP to be pool allocated
instead of malloc()ed, and remove the 2 pointer sized secret header cost
of each malloc allocation block.
first number on the left is size of the body struct in
bytes, on a 64b CPU.
Steps to Reproduce
C debugger, look at array PL_body_roots. Look at body_details struct in
sv_inline.h.Expected behavior
A smaller PL_body_roots array. More memory returned to OS after heavy subs, or
less peak memory usage, since arena pools have less empty slots in them
towards their ends. More common perl core fixed length, or really ALL core
fixed length structs come from pool allocators, not malloc.
Remember each pool chuck is a unit of 0x1000 or 4096 bytes, minus fixed 10-100 bytes.
Perl configuration
The text was updated successfully, but these errors were encountered: