On Sun, 19 Jan 2020 12:45:57 +0000, Anupam Kapoor said:

> > Note that in this case, "naively" includes "not remembering to consider
> > that the page being unmapped may have contained data we'd rather
> > have kept by flushing the page to disk" :)
>
> but is it that bad ?
>
> before marking a page unmappable, the application has full control
> over what it wants to do with the data, and can choose to dump it
> to the appropriate destination.

Yes, but now you're getting into more code that has to be written, including
code to marshal things like binary trees into a savable format, and more code
to read them back at a later time. Plus all the fun if the tree has hundreds of thousands
or millions of entries, and how to deal with it if some parts of the tree have been
released and saved to disk, or if the 4K page contained members of several different
data structures - in other words, you probably just decided to write your own backing store,
garbage collector, and virtual object manager for your heap.

As I said - it's a naive approach that ends up following the 90/10 rule:
the easy 90% of it takes the first 90% of the time to code it, and the difficult
10% takes the other 90% of the time... :)