2010/6/4 Eliot Miranda <eliot.miranda@gmail.com>
2010/6/4 Mariano Martinez Peck <marianopeck@gmail.com>
2010/6/3 Eliot Miranda <eliot.miranda@gmail.com>
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-tp1296... 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 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