Got lots of data, but don't know where to put it? Conventional storage methods let you down, time after time? ColdStore might be what you're looking for...
- Construct objects within a program (structs, classes, etc) which persist, so when the program stops and is restarted the objects are there and available to the program as if they'd been there all the time: pointers and references to them still work.
- Change library code implementing objects (so long as the object layout and virtual method table doesn't change) without having to reconstruct the store.
- Allocate memory in `extents' or `neighborhoods' such that the allocations are clustered onto a small (not to say minimal) set of hardware pages. This means code referencing those neighborhoods is more likely to find the objects it needs already swapped into RAM from the store.
- Optionally use a whole library of classes designed or adapted to work well with extent-based allocation: array/lists, Tuples, dynamic strings, dictionary (content addressable array), BTree, Symbols, Namespaces, big integers, arbitrary precision float, regular expresisons, more added all the time.
- Leave out the parts of the system you don't need.
Why ColdStore? An explanation of what we're up to.
The nitty-gritty: an explanation of ColdStore's design, what it
does, and what it might be used for.
Get it, compile it, run it, tweak it. Lather, rinse,
repeat: all with the fresh smell of GNU.
We think that ColdStore has potential. Here's what's in the
offing: from the nearly feasible to the bright blue sky. You can
probably help us out here.
Though it sometimes feels that way, we're not the only ones thinking
about these things. A few references to articles on object persistence
and all that gubbins.
Praise the visionaries behind this thing; alternatively,
berate the guilty parties.
That Oscar acceptance speech in full.
Hosted By: