BenGoldberg1/gist:7a87041b6148afea8bca5717f9660cbc

## gistfile1.txt
This is an idea for a memory allocator which whose purpose is to make it much faster to save and load lots of pieces of data.

The fucntions of the library would be named persistant_malloc, persistant_free, persistant_realloc, persistant_calloc, persistant_pointer2integer, persistant_integer2pointer, all of which take a first argument which has a handle which contains all of the data tables typical of a malloc library.  There would also be something like persistant_malloc_fopen, persistant_malloc_fsave, persistant_malloc_fclose, for creating the handle, storing it's contents to disk, and freeing the handle.

None of the three allocation functions will use sbrk to allocate memory, nor do they use mmap with MAP_ANONYMOUS to ask the OS to give them new blank pages; instead, they lengthen a certain disk file, and then mmap the region from the file's former end to it's new end, with the flags MAP_SHARED, and PROT_READ | PROT_READ.

The pointer2integer function gets a handle and a pointer; the pointer must have been one returned by one of the allocation functions (on the same handle), and not yet freed, OR it must be a pointer which was constructed from such a pointer.  The number it returns isn't necessarily an offset into the disk file, but it could be.

The integer2pointer function takes a handle an integer returned by pointer2integer, and, if it can, returns the unique valid pointer which would yield the same integer if the pointer were passed back to pointer2integer.  If the number doesn't correspond to a valid pointer (e.g. the number is negative, or beyond the end of the disk file, or to something which was persistant_free()d, etc) or if there are two or more such valid pointers, the process will abort.

The integer2pointer function should only be used shortly after a handle has been constructed from a preexisting disk file, as the entire file will have been loaded with a single call to mmap.

The handle probably will contain, in addition to malloc-related-tables, the filename for debugging purpose, and will certainly contain the filedescriptor for ftruncate and mmap.

The persistant_fsave *might* do little more than copy the backing file (preferably with reflink) to the new filename, and write to disk the contents of the memory allocation tables.

No extra work needs to be done for saving text, numbers, unstructured data; due to the power of mmap, it is *already* on disk.

There *might* be (but doesn't need to be), some sort of "persistant_register_pointer" and "persistant_unregister_pointer" functions, each of which takes a handle and a pointer to pointer; if these functions exist and are used, when saving is done, it will be as if each registered pointer were replaced with the result of doing pointer2integer just before saving, and the opposite when the file is loaded.
	This is an idea for a memory allocator which whose purpose is to make it much faster to save and load lots of pieces of data.

	The fucntions of the library would be named persistant_malloc, persistant_free, persistant_realloc, persistant_calloc, persistant_pointer2integer, persistant_integer2pointer, all of which take a first argument which has a handle which contains all of the data tables typical of a malloc library. There would also be something like persistant_malloc_fopen, persistant_malloc_fsave, persistant_malloc_fclose, for creating the handle, storing it's contents to disk, and freeing the handle.

	None of the three allocation functions will use sbrk to allocate memory, nor do they use mmap with MAP_ANONYMOUS to ask the OS to give them new blank pages; instead, they lengthen a certain disk file, and then mmap the region from the file's former end to it's new end, with the flags MAP_SHARED, and PROT_READ \| PROT_READ.

	The pointer2integer function gets a handle and a pointer; the pointer must have been one returned by one of the allocation functions (on the same handle), and not yet freed, OR it must be a pointer which was constructed from such a pointer. The number it returns isn't necessarily an offset into the disk file, but it could be.

	The integer2pointer function takes a handle an integer returned by pointer2integer, and, if it can, returns the unique valid pointer which would yield the same integer if the pointer were passed back to pointer2integer. If the number doesn't correspond to a valid pointer (e.g. the number is negative, or beyond the end of the disk file, or to something which was persistant_free()d, etc) or if there are two or more such valid pointers, the process will abort.

	The integer2pointer function should only be used shortly after a handle has been constructed from a preexisting disk file, as the entire file will have been loaded with a single call to mmap.

	The handle probably will contain, in addition to malloc-related-tables, the filename for debugging purpose, and will certainly contain the filedescriptor for ftruncate and mmap.

	The persistant_fsave might do little more than copy the backing file (preferably with reflink) to the new filename, and write to disk the contents of the memory allocation tables.

	No extra work needs to be done for saving text, numbers, unstructured data; due to the power of mmap, it is already on disk.

	There might be (but doesn't need to be), some sort of "persistant_register_pointer" and "persistant_unregister_pointer" functions, each of which takes a handle and a pointer to pointer; if these functions exist and are used, when saving is done, it will be as if each registered pointer were replaced with the result of doing pointer2integer just before saving, and the opposite when the file is loaded.