Thanks for the great content! A minor note for those using glibc version 2.34 and higher: glibc no longer installs its shared objects under versioned file names (like libc-2.31.so as shown in this video). Instead, now the shared objects are installed under their ABI sonames, such as libc.so.6, which was previously a symbolic link but is now the actual shared object.
This looks very informative also for hiperf coding! Can't wait for next chapter - instant subscribe! I am wondering if there is difference for realloc-ing the mmap-ed big areas and the arena areas (I suspect maybe only the arena ones gain by that?) and also to just see how this all works. It looked like there are only a few bytes between your allocations - did not spot if its dependant on size or not and such things. Very good video - also teached a lot about gdb (I also knew a lot of it and was not annoyed for things I considered basic - good video format).
Thank you for your feedback. There will be at least six more videos following this one on heap. Regarding your question about the different behavior of realloc when it comes to mmaped blocks or arenas, it depends on the availability of the mremap system call. If HAVE_MREMAP is enabled in glibc then the mremap syscall is used to re-map the mmaped block in a different region of virtual memory so that it can support the larger/smaller size. However, if that feature is not enabled then realloc of mmaped chunk would be rather inefficient as a new mmaped block will be created and all memory copied over from old location to the new one. You can observe this behavior in the lines following this part of the code: github.com/bminor/glibc/blob/master/malloc/malloc.c#L3460 I will talk about the bytes in between blocks (metadata) in my next video which will be published soon.
@@deeplinux2248 Very interesting. In the arena way of doing things I am also interested to see how that works and how realloc works there. I am on linux and from the code comments I suspect HAVE_MREMAP is defined by default but can I check if a glibc has it defined? Comments imply it is so it would work to realloc properly. Keep up the good work ;-)
@@u9vata I encourage you to read the internal implementation of realloc. For example here codebrowser.dev/glibc/glibc/malloc/malloc.c.html#_int_realloc Essentially the order of doing realloc on an arena (not mmaped) block is as follows: If new size is less than current then split off the extra size as a free block. else extend into top chunk if adjacent to it else extend into adjacent free block else just malloc a new block large enough and copy everything over from old to new and then free the new if all fails try another arena
Thanks for the great content!
A minor note for those using glibc version 2.34 and higher: glibc no longer installs its shared objects under versioned file names (like libc-2.31.so as shown in this video). Instead, now the shared objects are installed under their ABI sonames, such as libc.so.6, which was previously a symbolic link but is now the actual shared object.
This channel is amazing. Keep the great work mate 🎉
Glad you enjoy it!
please keep creating video like this
Me too, subcribed. A bit deep but very informative an interesting. 😍
Great video. Thank you for making these.
Glad you like them!
This looks very informative also for hiperf coding! Can't wait for next chapter - instant subscribe!
I am wondering if there is difference for realloc-ing the mmap-ed big areas and the arena areas (I suspect maybe only the arena ones gain by that?) and also to just see how this all works. It looked like there are only a few bytes between your allocations - did not spot if its dependant on size or not and such things. Very good video - also teached a lot about gdb (I also knew a lot of it and was not annoyed for things I considered basic - good video format).
Thank you for your feedback. There will be at least six more videos following this one on heap. Regarding your question about the different behavior of realloc when it comes to mmaped blocks or arenas, it depends on the availability of the mremap system call. If HAVE_MREMAP is enabled in glibc then the mremap syscall is used to re-map the mmaped block in a different region of virtual memory so that it can support the larger/smaller size. However, if that feature is not enabled then realloc of mmaped chunk would be rather inefficient as a new mmaped block will be created and all memory copied over from old location to the new one. You can observe this behavior in the lines following this part of the code:
github.com/bminor/glibc/blob/master/malloc/malloc.c#L3460
I will talk about the bytes in between blocks (metadata) in my next video which will be published soon.
@@deeplinux2248 Very interesting. In the arena way of doing things I am also interested to see how that works and how realloc works there. I am on linux and from the code comments I suspect HAVE_MREMAP is defined by default but can I check if a glibc has it defined? Comments imply it is so it would work to realloc properly.
Keep up the good work ;-)
@@u9vata I encourage you to read the internal implementation of realloc. For example here
codebrowser.dev/glibc/glibc/malloc/malloc.c.html#_int_realloc
Essentially the order of doing realloc on an arena (not mmaped) block is as follows:
If new size is less than current then split off the extra size as a free block.
else extend into top chunk if adjacent to it
else extend into adjacent free block
else just malloc a new block large enough and copy everything over from old to new and then free the new
if all fails try another arena
You can use `info proc mappings` to see the memory map of the process like what `cat /proc/$pid/map` does
Nice