3 ms·
How would this proposed mechanism allow that, and what about the current workings of virtual memory disallow it? One can already do this with realloc() (https:
by scott_s 8y ago
How would this proposed mechanism allow that, and what about the current workings of virtual memory disallow it?
One can already do this with realloc() (https://linux.die.net/man/3/realloc https://linux.die.net/man/3/realloc). And if you don't want to use the malloc family, but instead want to manage your virtual memory yourself, you can easily allocate large sections of virtual memory and then manage it yourself - which would include enabling behavior such as growing arrays. (Even though you're really just re-implementing realloc-like behavior yourself.)
And to make sure we're on the same page (ha), I want to reiterate that there is a big difference between virtual and physical memory. You can allocate virtual memory without allocating physical memory.
- CJefferson 8y agoThis is kind of the point of this whole post :) reserving lots of virtual memory causes posts like this, where people complain about how much memory you are "using".
- scott_s 8y agoI think that just kicks the ball further down the court, as it's yet another thing to track. It think it's better to just explain that (for the most part), high virtual memory usage isn't a problem. But as someone pointed out above, FreeBSD does have a facility for it, which is interesting.
- koala_man 8y agoI misunderstood what it was that you didn't see the value of. The original point was entirely to avoid scaring newbies who can't tell virtual from physical, while still being liberal with your virtual usage. Haskell with GHC has a great solution: just allocate 1TB up front. A newbie does not need improved tooling, a reworked memory system or any education to realize that this can't possibly be RAM.