3 ms·
> However, the memory in question here is, for the most part, not freshly allocated, but was in use once. Because the author does not differentiate between vir
by scott_s 8y ago
> However, the memory in question here is, for the most part, not freshly allocated, but was in use once.
Because the author does not differentiate between virtual and physical memory, I can’t agree with that. It’s quite possible most of the memory “freed” was never in use. In which case, there’s not much benefit. And there is the probable downside that allocation heavy applications will pay a lot more.
- microtherion 8y ago> It’s quite possible most of the memory “freed” was never in use. Given the allocation patterns shown, it would seem to me that if two blocks are still in use, it's fairly likely that the region in between also were in use once (there may be exceptions due to pools etc, but generally memory is parcelled out in a linear fashion). > And there is the probable downside that allocation heavy applications will pay a lot more. What would the cost be? All that would happen is that the free pages are marked as clean. I'm sure that's not entirely free, but bound to be considerably cheaper than paging the page out and in again.
- scott_s 8y ago> What would the cost be? All that would happen is that the free pages are marked as clean. That's a minor page fault. You get an OS-level exception, switch to kernel mode, process the page fault by marking the page as loaded, then switching back to user mode. That is expensive if you do it a lot. > but bound to be considerably cheaper than paging the page out and in again. Yes, of course, a minor page fault is cheaper than a major page fault. But both are more expensive than no page fault, which is what happens if you just never free the page to the OS and there's plenty of available physical memory.