GMP and Win32 Memory Management
Emmanuel.Thome at normalesup.org
Mon Dec 4 11:29:47 CET 2006
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
Really, if you want checkpointing and resuming, that's your application's
job, not the library's.
More information about the gmp-discuss