2010/6/4 Eliot Miranda <[email protected]> > > > 2010/6/4 Mariano Martinez Peck <[email protected]> > > >> >> 2010/6/3 Eliot Miranda <[email protected]> >> >> Hi Mariano, Hi All, >>> >>> response below. But does anyone have any tests for the image segment >>> primitives? I'm refactoring them and would like some tests. >>> >> >> Hi Eliot. First, congratulations!! I though several times to refactor >> the primitives what I was not brave enough. I was not confidence of myself >> hahaha >> >> Originally, ImageSegment didn't have a single test. Only some class side >> examples that in Pharo at least were not even working. Adrian Lienhard wrote >> the first 2 or 3 tests for them. Then I needed to understand ImageSegment >> for my PhD, and the best way to understand them were writing unit tests ;) >> >> So, now if you take a Pharo 1.1 image you will see there are 26 tests. The >> classes are ImageSegmentTest, ImageSegmentTestExport and >> ImageSegmentTestSwap. The tests are quite simple and cover not too much. >> They can be improved and there are more to write. They may be even not >> completly correct as I wrote them to understand ImageSegment, not because I >> already understood them ;) >> >> In addition, there is one failing that I yet don't understand why: >> #testOutPointers3 >> I asked in mailing list but not really an answer in my opinion: >> >> http://forum.world.st/Something-I-don-t-understand-with-ImageSegments-tp1296982p1296982.html >> If you know why it is failing, tell me :) >> >> > I wrote a test yesterday anyway. Perhaps we can combine at some stage. I > can certainly use the tests you've written though. Thanks! > > Great. If you want feel free to attach your test and I commit it. Or you create an issue and you do it by yourself.
> > >> >>> >> >> Ok...but where is the roots of the system? it is the instVar rootTable of >> ObjectMemory? so all the root table is also marked? >> > > The roots of the system are > - the specialObjectsArray > - the current context > - the extraRoots table (addGCRoot/removeGCRoot's underlying table) > - suspended callbacks (processes using the FFI's callback facility) > > While the specialObjectsArray contains references to known classes (which > indirectly refer to Smalltalk and the entire class hierarchy) and to the > process scheduler (Smalltalk associationAt: #Processor) it also contains the > external semaphore table, the Character table (byte character instances) and > the specialSelectors table (for special selector sends). > > OK, I didn't know all this :) > >> At the beginning I though it was this that you are saying. But then I >> check in the senders of markAndTraceInterpreterOops and you can see in >> ObjectMemory >> markPhase that it does: >> >> "trace the interpreter's objects, including the active stack >> and special objects array" >> self markAndTraceInterpreterOops. >> statSpecialMarkCount := statMarkCount. >> "trace the roots" >> 1 to: rootTableCount do: [:i | >> oop := rootTable at: i. >> self markAndTrace: oop]. >> 1 to: extraRootCount do:[:i| >> oop := (extraRoots at: i) at: 0. >> (self isIntegerObject: oop) ifFalse:[self markAndTrace: oop]]. >> >> So...it is manually iterating the table. Why? shouldn't be done as you >> told me? >> > > The rootTable (better known as a remembered set) is part of the garbage > collector and contains any and all old objects that may reference a young > object. These objects are roots for an incremental GC, and they get voided > at the start of a full GC and after an incrementalGC. See clearRootsTable. > > > In summary, my question is: is these code doing this (iterating the table) >> even if it is not necessary or ImageSegment should also do it? >> > > It's an essential part of the generational GC implementation. It is > nothing to do with tracing for image segments. > > > Ok...so, my problem was I though that rootTable were indeed the roots of the system, not a particular GC table. Then, I confused because as in GC it needed to iterate it, I though I had to do that also in ImageSegment. > This would mark all objects in the system were it not for the fact that the >>> primitive marks the rootArray and so markInterpreterOops does not marl >>> objects /only/ reachable from the rootArray. So once the rootArray objects >>> have been unmarked, only those objects that should go in the image segment >>> are unmarked. >>> >>> So the primitive works by >>> - marking the objects in rootArray, preventing marking of objects >>> reachable from them in the next step >>> - recursively marking all objects reachable from the roots (except those >>> already marked) >>> - unmarking root objects, leaving the transitive closure of objects >>> accessible from the roots and no where else unmarked >>> - writing the unmarked objects to an image segment >>> >>> >> yes, this is clear :) >> >> Thanks for the help. >> >> Mariano >> > > cheers > Eliot > > >> >> >>> >>> HTH >>> Eliot >>> >>> >>>> You can see the comment: "Then do a mark pass over all objects" and even >>>> without the comment it makes sense to mark all objects in order to detect >>>> outPointers. >>>> >>>> Does anyone has a hint? >>>> >>>> Thanks >>>> >>>> Mariano >>>> >>>> _______________________________________________ >>>> 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
