<div dir="ltr">Just a quick note I would like to share....<div>For my PhD, I did investigate ImageSegment very very deeply:</div><div><br></div><div><a href="http://dl.acm.org/citation.cfm?id=2076323">http://dl.acm.org/citation.cfm?id=2076323</a><br></div><div><a href="http://www.slideshare.net/MarianoMartinezPeck/2010-smalltalkspeckobject-swapping">http://www.slideshare.net/MarianoMartinezPeck/2010-smalltalkspeckobject-swapping</a><br></div><div><br></div><div>I didn't want to write Fuel just because. I took quite a lot of time to understand how ImageSegment primitives worked. From that effort, I remember a few conclusions:</div><div><br></div><div>1) I found only few users of ImageSegment</div><div>2) The few users I found, were NOT using the real purpose of ImageSegment, that is, object swapping. It was used instead as an object serializer. For that, they use #writeForExportOn: which ended up using SmartRefStream for the rest of the objects. </div><div>3) I noticed I could achieve the same performance or even better with an OO serializer built at the language side, with all the benefits this means. Of course, having Cog helped here....</div><div><br></div><div>In the Fuel paper: <a href="http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf">http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf</a> </div><div>you can find some benchmark comparison agains IS. Also in my PhD: <a href="http://rmod.lille.inria.fr/archives/phd/PhD-2012-Martinez-Peck.pdf">http://rmod.lille.inria.fr/archives/phd/PhD-2012-Martinez-Peck.pdf</a></div><div><br></div><div>Cheers, </div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 9:56 PM, <span dir="ltr"><<a href="mailto:jvuletich@dc.uba.ar" target="_blank">jvuletich@dc.uba.ar</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eliot,<br>
<span class=""><br>
> Hi All,<br>
><br>
> I want to check my understanding of reference semantics for image<br>
> segments as I'm close to completing the Spur implementation. Specifically<br>
> the question is whether objects reachable only through weak pointers<br>
> should<br>
> be included in an image segment or not.<br>
><br>
> Remember that an image segment is created from the transitive closure of<br>
> an<br>
</span>> Array of root objects, the *segment roots*. i.e. we can think of an image<br>
<span class="">> segment as a set of objects created by tracing the object graph from the<br>
> segment roots.<br>
><br>
> The segment always includes the segment roots. Except for the roots,<br>
> objects are excluded from the segment that are also reachable form the<br>
</span>> roots of the system (the *system roots*, effectively the root environment,<br>
<span class="">> Smalltalk, and the stack of the current process).<br>
><br>
> Consider a weak array in the transitive closure that is not reachable from<br>
> the system roots, and hence should be included in the segment. Objects<br>
> referenced from that weak array may be in one of three categories<br>
><br>
> - reachable from the system roots (and hence not to be included in the<br>
> segment)<br>
</span>> - *not* reachable form the system roots, but reachable from the segment<br>
<span class="">> roots via strong pointers (and hence to be included in the segment)<br>
</span>> - *not* reachable form the system roots, *not* reachable from the segment<br>
<span class="">> roots via strong pointers<br>
><br>
> Should this last category be included or excluded from the segment? I<br>
> think that it makes no difference, and excluding them is only an<br>
> optimization. The argument is as follows. Imagine that immediately after<br>
> loading the image segment there is a garbage collection. That garbage<br>
> collection will collect all the objects in the last category as they are<br>
> only reachable from the weak arrays in the segment. Hence we are free to<br>
> follow weak references as if they are strong when we create the image<br>
> segment, leaving it to subsequent events to reclaim those objects.<br>
><br>
> An analogous argument accounts for objects reachable from ephemerons. Is<br>
> my reasoning sound?<br>
> --<br>
> best,<br>
> Eliot<br>
><br>
><br>
<br>
</span>I think you are right. But there is a risk of somehow, someone, gaining a<br>
strong reference to the object after the image segment was created,<br>
breaking our invariants when the segment is loaded again.<br>
<br>
An object might be (not reachable / strongly reachable / weakely<br>
reachable) from system roots and / or segment roots. This gives us 9<br>
possibilities.<br>
Six of them are easy (and I'll not go into them). The other three are<br>
tricky:<br>
<br>
a- Not reachable from system roots. Weakely reachable from segment roots.<br>
Do not include them. It is best to run a GC before building the image<br>
segment, to get rid of them (run termination, etc). This is to avoid the<br>
risk of the object gaining somehow a strong reference after the segment is<br>
built, making the segment miss the weak ref to it. Doing this way would<br>
also mean that any objects affected by termination would be consistent,<br>
both in the image and in the segment.<br>
<br>
b- Weakely reachable from system roots. Weakely reachable from segment<br>
roots.<br>
Do not include them. If the object manages to survive by gaining a strong<br>
ref from the system roots, the weak ref will be repaired on segment load<br>
(Am I right on this?) If the original object was included in the segment,<br>
then on segment load it would point to a duplicate object that is about to<br>
be collected (and maybe terminated?) In any case, doing this way would also<br>
mean that any objects affected by termination would be consistent, both in<br>
the image and in the segment.<br>
<br>
c- Weakely reachable from system roots. Strongly reachable from segment<br>
roots.<br>
Do include them. It seems reasonable to run a GC and get rid of them after<br>
unloading the segment, to avoid the risk of the object gaining somehow a<br>
strong ref in the image, and being duplicated on segment load. But doing as<br>
I say means that we would be loading into the image an object that was<br>
already terminated, although in the state it had before running<br>
termination. Not really sure if this is ok. There could be some risk of<br>
objects in the segment being in some pre-termination state, with some<br>
objects in the image being in some after-termination state. In any case,<br>
this would suggest bad design... So perhaps it makes sense to throw an<br>
exception in these cases?<br>
<br>
I hope this rant is of use.<br>
<br>
Cheers,<br>
Juan Vuletich<br>
<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br>
</div>