3 ms·

What language independent allocator? I'm unaware of any memory interfaces in programming languages that aren't specific to that language. What would you use in

What language independent allocator? I'm unaware of any memory interfaces in programming languages that aren't specific to that language. What would you use instead of malloc and free?

SubjectToChange 3y ago
I suppose they meant a "libc independent" allocator, e.g. jemalloc/tcmalloc/mimalloc/etc. Although, using such allocators comes with complications of their own: https://lwn.net/Articles/761502/ https://lwn.net/Articles/761502/
p_l 3y ago
The OS provided memory allocators - HeapAlloc, its wrappers GlobalAlloc and LocalAlloc (remainders of 16bit era), VirtualAlloc (page granularity, can be compared to MAP_ANONYMOUS with mmap(), and CoTaskMemAlloc which can be shared across COM processes + their respective "free" functions. malloc() is explicitly called out in documentation as "runtime dependant". Similarly other OSes used to have memory allocation services that weren't linked in any way to a language runtime - VMS has several calls, all language independent, ranging from low-level equivalents of mmap() to malloc-alternative. And yes, a big chunk of Windows portability is that various APIs use those language-independent calls internally, and so can developer in order to avoid creating issues - and documentation promotes those language independent methods. At no point you get into situation with Windows API that you call free() on memory allocated by malloc() from a different libc. In comparison, the available language-independent APIs without using any special libraries on Linux, are to directly call mmap() and sbrk() through inline assembly (beware the glibc wrappers!).
- account42 3y ago
  malloc in (g)libc isn't any more language dependent than HeapAlloc or VirtualAlloc. Both have a stable ABI that can be used by any language.
  - p_l 3y ago
    HeapAlloc and VirtualAlloc do not bring the whole language runtime with them, like glibc does, nor are they specified as part of a specific language runtime only (the unix primitive for allocating memory is sbrk() and mmap(), not malloc()). And with how applications are linked by default on linux, whoever loads glibc first sets the stage for every other module in the program, which makes for "fun" errors when you get a library that happens to be compiled with newer version (or older). And even if you force windows-style linking (good luck, lots of infrastructure needed), you end up dealing with modules passing each other malloc()ed blocks and possibly trying to call free() from different allocator on it. Anyway, for all practical purposes, glibc has no stable ABI at all.

What language independent allocator? I'm unaware of any memory interfaces in programming languages that aren't specific to that language. What would you use instead of malloc and free?

SubjectToChange 3y ago

I suppose they meant a "libc independent" allocator, e.g. jemalloc/tcmalloc/mimalloc/etc. Although, using such allocators comes with complications of their own: https://lwn.net/Articles/761502/ https://lwn.net/Articles/761502/

p_l 3y ago

The OS provided memory allocators - HeapAlloc, its wrappers GlobalAlloc and LocalAlloc (remainders of 16bit era), VirtualAlloc (page granularity, can be compared to MAP_ANONYMOUS with mmap(), and CoTaskMemAlloc which can be shared across COM processes + their respective "free" functions. malloc() is explicitly called out in documentation as "runtime dependant". Similarly other OSes used to have memory allocation services that weren't linked in any way to a language runtime - VMS has several calls, all language independent, ranging from low-level equivalents of mmap() to malloc-alternative. And yes, a big chunk of Windows portability is that various APIs use those language-independent calls internally, and so can developer in order to avoid creating issues - and documentation promotes those language independent methods. At no point you get into situation with Windows API that you call free() on memory allocated by malloc() from a different libc. In comparison, the available language-independent APIs without using any special libraries on Linux, are to directly call mmap() and sbrk() through inline assembly (beware the glibc wrappers!).

account42 3y ago
malloc in (g)libc isn't any more language dependent than HeapAlloc or VirtualAlloc. Both have a stable ABI that can be used by any language.
- p_l 3y ago
  HeapAlloc and VirtualAlloc do not bring the whole language runtime with them, like glibc does, nor are they specified as part of a specific language runtime only (the unix primitive for allocating memory is sbrk() and mmap(), not malloc()). And with how applications are linked by default on linux, whoever loads glibc first sets the stage for every other module in the program, which makes for "fun" errors when you get a library that happens to be compiled with newer version (or older). And even if you force windows-style linking (good luck, lots of infrastructure needed), you end up dealing with modules passing each other malloc()ed blocks and possibly trying to call free() from different allocator on it. Anyway, for all practical purposes, glibc has no stable ABI at all.