On Wed, Dec 9, 2009 at 9:40 AM, Adrian Lienhard <adi@netstyle.ch> 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 <
> marianopeck@gmail.com> wrote:
>
>>
>>
>> On Tue, Dec 8, 2009 at 5:07 PM, Adrian Lienhard <adi@netstyle.ch>
>> wrote:
>>
>>>
>>> On Dec 8, 2009, at 12:08 , Mariano Martinez Peck wrote:
>>>
>>>> On Fri, Dec 4, 2009 at 12:05 PM, Adrian Lienhard <adi@netstyle.ch>
>>>> 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
>>> 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