On Thu, Dec 10, 2009 at 9:21 AM, Adrian Lienhard <[email protected]> wrote:
> Hi Mariano, > > I don't understand your question(s)... If you have some code, that > would probably help. > > Ok. I commit a test case called testInstallSegmenetWithObjectRemoved which is failing in the version Tests-Mariano.40 of the repository http://www.squeaksource.com/MarianoPhD Maybe what is happening is that "anExternalObject" is not being garbageCollected because there are references from the outPointers array. That sounds logic. What do you think? Kind regards, Mariano > Cheers, > Adrian > > > On Dec 9, 2009, at 21:06 , Mariano Martinez Peck wrote: > > > 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 > > > _______________________________________________ > 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
