logoalt Hacker News

jeffbee • today at 7:28 PM • 5 replies • view on HN

This is why memory allocators should be linked into applications and should not be considered operating system components.


Replies

GuB-42 • today at 9:10 PM

If an OS update gives me a better allocator, I want every app to take advantage of it. Same idea with other libraries, if I update a library for reading zip files to make it go faster, or to fix a vulnerability, I want every application that uses that library to take advantage of it.

This is a debatable position. Linux distros usually do this, but a lot of modern applications ship with all their dependencies. I'd say the former is more efficient and generally better from a user perspective and the latter is more stable and is generally better from a developer/maintainer perspective. Open source encourages the former, proprietary software encourages the latter.

fredoralive • today at 9:29 PM

How does the memory allocator statically linked into the application request a new memory allocation into it's address space (sbrk or VirtualAlloc etc.)? Allocating memory will in most cases involve calling into the kernel, it's kinda a core function of a kernel. It has to have some link externally to the programme, directly or indirectly.

pcwalton • today at 7:48 PM

Userland system DLLs need to allocate memory too.

➕ show 1 reply
rowls66 • today at 7:36 PM

And when you are running more than one application at the same time how is that supposed to work?

➕ show 3 replies
Spivak • today at 9:08 PM

In 20 years we'll have finally reached the logical conclusion to all of this that there shouldn't be separate os components you link against and your "OS" will just be manager of lightweight VMs.

Now you can just ship the user your machine and software can theoretically be immortal.