Tim Barbour writes
>>>>>> "Tony" == Tony Davie <[EMAIL PROTECTED]> writes:
>
> Tony> This has well know disadvantages. Simon has already pointed
> Tony> out that it's not relocatable. It's also limited to the size
> Tony> of virtual memory and takes up that amount of space even
> Tony> though most of it may not be used. Loading a complete
> Tony> persistent memory at once is overkill. You should load it's
> Tony> objects lazily and only store away accessible stuff at
> Tony> commit time.
>
>Relocation and address space are not such a problem on 64-bit
>machines. Not having enough address space is really a disadvantage of
>32-bit machines, not persistence.
>
>I was suggesting using memory-mapped files, using e.g. mmap. Such a
>file is mapped instantly into the address space, but its contents are
>paged in and out on demand. A mmapped file takes up disk space only
>for the populated part of its address region, and does not take up
>virtual memory. It takes up real memory only according to demand for
>pages from the file, in much the same way as buffer blocks do on a
>conventional file.
>
>Tim
>--
>
A much more serious problem is that, in a persistent system, one may want
to extend the persistent store by adding new objects to it and making use,
in newly written programs, of the objects found there already. It's then
very inconvenient to treat the store in one monolithic lump. And anyway
didn't this start out about how to do I/O on binary data. Surely you don't
want to output everything every time you output a single item, only those
things reachable from it.
Tony Davie, Computer Science, St.Andrews University, North Haugh, St.Andrews
Scotland, KY16 9SS, Tel: +44 1334 463257, Fax: +44 1334
463278
mailto:[EMAIL PROTECTED] Home: http://www.dcs.st-and.ac.uk/~ad/Home.html
Handel Index and Chronology:
http://bruichladdich.dcs.st-and.ac.uk/HandelWWW/HandelCat.html
Limerick Archive:
http://bruichladdich.dcs.st-and.ac.uk/LimericksDir/Limericks.html
'There is magic in the web' - Othello, Act 3, Scene 4
