Hi folks. I have a simple question. Suppose I have a file in disk that has a "pointer" to an object X that is in the image. What can I store from X in the file? Two options: the address in memory or the hash.
If I savethe address, the object X can be moved by the GC, and thus, the address can become incorrect in the file. I don't want to update the disk files in case objects are moved. If I save the hash of X, how can I then localize that object in memory? Hash is 12 bits...so it is not enough to find that object...(otherwise there would be only 4096 objects) So....the question is, what should I save from object X in the file and what should I do to be able to localize it, some time after (even when the X is moved by the GC). Sorry for my ignorance about the hash. Thank you very much in advance, Mariano _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi Mariano,
What I suggest as a solution is to store an array of your objects in memory and in the file you refer to objects through indices into this array. HTH, Adrian On Jul 19, 2010, at 14:25 , Mariano Martinez Peck wrote: > Hi folks. I have a simple question. Suppose I have a file in disk that has a > "pointer" to an object X that is in the image. What can I store from X in > the file? Two options: the address in memory or the hash. > > If I savethe address, the object X can be moved by the GC, and thus, the > address can become incorrect in the file. I don't want to update the disk > files in case objects are moved. > If I save the hash of X, how can I then localize that object in memory? > Hash is 12 bits...so it is not enough to find that object...(otherwise there > would be only 4096 objects) > > So....the question is, what should I save from object X in the file and what > should I do to be able to localize it, some time after (even when the X is > moved by the GC). > > Sorry for my ignorance about the hash. > > Thank you very much in advance, > > Mariano _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
See DiskProxy in Squeak...
On Mon, Jul 19, 2010 at 7:25 AM, Mariano Martinez Peck <[hidden email]> wrote: > > Hi folks. I have a simple question. Suppose I have a file in disk that has a "pointer" to an object X that is in the image. What can I store from X in the file? Two options: the address in memory or the hash. > > If I savethe address, the object X can be moved by the GC, and thus, the address can become incorrect in the file. I don't want to update the disk files in case objects are moved. > If I save the hash of X, how can I then localize that object in memory? Hash is 12 bits...so it is not enough to find that object...(otherwise there would be only 4096 objects) > > So....the question is, what should I save from object X in the file and what should I do to be able to localize it, some time after (even when the X is moved by the GC). > > Sorry for my ignorance about the hash. > > Thank you very much in advance, > > Mariano > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
Hi Mariano,
On Mon, Jul 19, 2010 at 5:25 AM, Mariano Martinez Peck <[hidden email]> wrote:
this is an issue in virtual object systems, object persistence and object distribution systems and has been the subject of considerable research and implementation in the 70's, 80's and 90's. You need to do a literature search (if Chris' suggestion of DiskProxy is insufficient). In general the hash is insufficient since it is not unique. A common approach (as Adrien points out) is to use a table in the image containing objects which have a persistent id and pass out the index into the table as the external id. This immediately raises a GC issue because even if the table is weak a cycle of references between objects in the table can render the isolated cycle uncollectable. Hence distributed garbage collection algorithms.
Two options: the address in memory or the hash. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |