On Wed, Dec 9, 2009 at 9:40 AM, Adrian Lienhard <[email protected]> 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 < > > [email protected]> wrote: > > > >> > >> > >> On Tue, Dec 8, 2009 at 5:07 PM, Adrian Lienhard <[email protected]> > >> wrote: > >> > >>> > >>> On Dec 8, 2009, at 12:08 , Mariano Martinez Peck wrote: > >>> > >>>> On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <[email protected]> > >>>> 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 > >>> [email protected] > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
