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 :)

continue answering above...


>
> 2010/6/3 Mariano Martinez Peck <[email protected]>
>
> ....
>>
>> But here I see it is only marking Interpreter oops, not all objects. And I
>> don't see where all objects are marked even in the code that follows this
>> little piece.
>>
>
> markInterpreterOops marks all objects accessible from the interpreter oops,
> including the specialObjectsArray, recursively marking any unmarked objects
> and their referents.  i.e. it marks all objects reachable from the roots of
> the system.
>

Ok...but where is the roots of the system?  it is the instVar rootTable of
ObjectMemory?   so all the root table is also marked?

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?

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?



> 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


>
> 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

Reply via email to