Hi Mariano, I don't understand your question(s)... If you have some code, that would probably help. Cheers, Adrian On Dec 9, 2009, at 21:06 , Mariano Martinez Peck wrote:
On Wed, Dec 9, 2009 at 9:40 AM, Adrian Lienhard <adi@netstyle.ch> wrote:
I don't have the VMMaker code at hand right now (or rather, don't have time to look at it ;)), but I guess that after that piece of code you pasted below there is a loop from the first field (BaseHeader+4) to the last non-weak field (lastFieldOffset) in which the non-weak fields are traced. Note, that if an object both fixed and indexable weak fields the latter are always located after the former. You can see the memory layout and object formats on the pages 9 and 10 of the slides [1] (from a lecture about VMs I gave recently).
Thanks for the explanation Adrian and the link Adrian...now, being a bit off-topic, I have the following situation about ImageSegment. I tried to reproduce it in a unit test, but I couldn't yet :(
Suppose I create a segment with a tree of objects. Suppose inside of that tree I have an object that refers to an external object called XXX, thus it is put in the outPointers. Then I extract the segment, I write it to disk, and I put a nil to the segment variable. After that, for some reason, my object XXX is garbage collected from my image. Then I want to load again my segment (reading the file and installling it). What happens ? it fails? If true, suppose I have already "installed" some other objects, what happen with those objects? is this atomic ?
Thanks a lot for anyone that can give me a hint.
Mariano
Cheers, Adrian
[1] http://www.adrian-lienhard.ch/presentations
On Dec 8, 2009, at 22:57 , Mariano Martinez Peck wrote:
On Tue, Dec 8, 2009 at 10:54 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Tue, Dec 8, 2009 at 5:07 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
On Dec 8, 2009, at 12:08 , Mariano Martinez Peck wrote:
On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
When you are creating your root of objects and you put symbols inside, they are not put in ourPointers but in ByteArray. This is due to the fact that the only object who is pointing to that symbol is inside the segment ?
To be precise, the symbols are also pointed to by the symbol table, but only by weak references. Since image segments use the GC mark logic, these pointers are not considered.
Ahhh ok. Now I see Symbol class >> rehash where it sets to SymbolTable := WeakSet
Now...my finally question is, where in the code you can see the GC only mark "normal" objects and that week objects are not being taken into account. Do you know ? I tried to search it but I didn't find it.
Sorry, I forgot to said I found this in ObjectMemory >> markAndTrace:
(self isWeakNonInt: oop) ifTrue: [ "Set lastFieldOffset before the weak fields in the receiver" lastFieldOffset := (self nonWeakFieldsOf: oop) << ShiftForWord. "And remember as weak root" weakRootCount := weakRootCount + 1. weakRoots at: weakRootCount put: oop. ] ifFalse: [ "Do it the usual way" lastFieldOffset := self lastPointerOf: oop. ].
But I don't know if this make sense or not.
Thanks!!
Mariano
What you do with this piece of code:
symbolHolder := Symbol allSymbols.
is to hold those symbols there. So, when ImageSegment uses the GC techniques to detect which objects are ONLY pointed from inside of the segment, the symbols is not found (because it is accessible trough that test) and thus, it goes to outPointers instead of ByteArray.
And of course, if it is in outPointers instead of ByteArray when the segment is loaded again, yo don't create a symbol again but use the same object (the one of the oop).
I am correct? or I understood anything ?
yes.
Cheers, Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project