GMP and Win32 Memory Management

[Emmanuel Thomé]

On Fri, Dec 01, 2006 at 11:09:30PM +0000, Jim White wrote:
> [...]
>
> The feature is called "memory-mapped files". Stripped
> down, this basically means you can create your own
> arbitrary virtual address space, which the OS will
> then page either directly to the paging disk, or to
> any file you care to provide.

FYI, the mmap() call also is standard to all unices, and provides what
you describe (to my understanding at least).

> [...]
> From a functional aspect, we can implement a "Save all
> key variables" and "restore all key variables" feature
> without doing any IO at all.  At the end of any
> execution, the mapped file is itself an IMAGE of all
> variables that were allocated in that address space.
> 
> To avoid potential problems such as the automatic
> resizing that can occur with mpz_t items, I think the
> best way to avoid this would be to implement the model
> as a "total solution" - as a set of "Custom
> Allocation" routines ("alloc" and "free" delegates).

sure you could do that, at least in theory. Indeed it would be necessary
to redefine custom memory handlers (with everything this entails) ; but...

- you can't be sure that your file will be mapped to memory at the same
  virtual address in all cases. And mpz_t's contain pointers. MAP_FIXED
  exists, but the OS only promises ``best effort''.
- such a thing would be word-size specific, and endianness-specific.
  Perhaps you don't care, but it's crucial in many contexts.
- And it doesn't pay that much: only thinking in detail about your
  computation will give you a guarantee that recovering from such a
  ``snapshot'' is meaningful (in the eventualy that your computation dies
  prematurely).

Really, if you want checkpointing and resuming, that's your application's
job, not the library's.

E.