Hacker News Reader

Comment by tetromino_ | Hacker News Reader

The main disadvantage of this approach is that to free memory, you must terminate the program. This is fine for a program which runs for a second, but is unusable for long-running processes and servers where you want to free memory after finishing any memory-intensive task so that everything else that your machine is running concurrently gets memory too.

View on HN

That’s not a problem for cases like a dispatcher that forks off a child per request and the memory intensive work is done in child space. In fact it can result in admirably simple and stable software. Things have probably changed but that used to be how telco software managed trunks.

madvise(MADV_FREE) (on *BSD) or madvise(MADV_DONTNEED) (on Linux) will remap the specified memory range to the zero page or leave it intact at the kernel’s discretion.

Congratulations, you have reinvented realloc and are no longer using simple static arrays.

Unlike realloc, though, I’m keeping element addresses stable.

(I’m actually somewhat conflicted about TFA’s idea, for what it’s worth, I just don’t think freeing memory is the most problematic part of it.)

You can let the OS write the page to disk freeing the memory so it can be used by other processes.

This is also fine for any long-running processes and servers where the "vector" in question is not expected to shrink its allocation, which I would guess is the main use of vectors. Shrinking a vector's allocation is a niche use, with some finicky APIs, that most programmers never needed or touched.

While shrinking vectors may not be that common, creating and deleting vectors for short lived operations in a long lived program is certainly not.

> Shrinking a vector's allocation is a niche use, with some finicky APIs, that most programmers never needed or touched.

Most programmers may not have touched those APIs but that doesn't mean that they didn't have a need for them.

Or have it evicted to swap. The kernel is pretty good at managing it automatically.

Writing garbage data you don't need anymore to disk (and reading it back for partial writes) is hardly an elegant solution.

It is elegant in the regard that the eviction only happens of page pressure warrants it. If the vector happens to be small enough, nothing special happens.

And you save on having to write some kind of allocator for it.

Static arrays of read-only memory-mapped files are the best vectors.

I'd say its a very elegant solution, it's a no code solution.

Reply on news.ycombinator.com