No, he wants to separate virtual address space allocation from physical memory backing allocation, with both still happening manually. It's a very reasonable request, and the benefit is that you can be guaranteed to have the address space while still only using a smaller max amount of physical memory.
I don't interpret that as the request. I interpret it as wanting virtual memory "allocated" but not counted against the processes' virtual memory allocation, and then getting a secondary mechanism to allocate the sorta-but-not-quite-allocated memory. I also don't see the value in that.
(I don't see any request for different physical memory allocation, so I assume that would still be handled by page faulting in the kernel.)
The value would be to be able to grow arrays and similar without relocation.
People do it all the time in real life, with area codes, zip codes, case numbers, etc.
For example, a long street full of strip malls in California will often have street numbers 50 apart to allow them to remain sequential even after new developments.
No one would complain that this is a wasteful use of precious street numbers, or that it deprives other streets of those numbers.
Imagine the nightmare if you periodically had to renumber all the buildings instead, like computers routinely have to.
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). 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.
I 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.
This 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".
I 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.
