<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&#39;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">&lt;<a href="mailto:jvuletich@dc.uba.ar" target="_blank">jvuletich@dc.uba.ar</a>&gt;</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>
&gt; Hi All,<br>
&gt;<br>
&gt;     I want to check my understanding of reference semantics for image<br>
&gt; segments as I&#39;m close to completing the Spur implementation.  Specifically<br>
&gt; the question is whether objects reachable only through weak pointers<br>
&gt; should<br>
&gt; be included in an image segment or not.<br>
&gt;<br>
&gt; Remember that an image segment is created from the transitive closure of<br>
&gt; an<br>
</span>&gt; Array of root objects, the *segment roots*. i.e. we can think of an image<br>
<span class="">&gt; segment as a set of objects created by tracing the object graph from the<br>
&gt; segment roots.<br>
&gt;<br>
&gt; The segment always includes the segment roots.  Except for the roots,<br>
&gt; objects are excluded from the segment that are also reachable form the<br>
</span>&gt; roots of the system (the *system roots*, effectively the root environment,<br>
<span class="">&gt; Smalltalk, and the stack of the current process).<br>
&gt;<br>
&gt; Consider a weak array in the transitive closure that is not reachable from<br>
&gt; the system roots, and hence should be included in the segment.  Objects<br>
&gt; referenced from that weak array may be in one of three categories<br>
&gt;<br>
&gt; - reachable from the system roots (and hence not to be included in the<br>
&gt; segment)<br>
</span>&gt; - *not* reachable form the system roots, but reachable from the segment<br>
<span class="">&gt; roots via strong pointers (and hence to be included in the segment)<br>
</span>&gt; - *not* reachable form the system roots, *not* reachable from the segment<br>
<span class="">&gt; roots via strong pointers<br>
&gt;<br>
&gt; Should this last category be included or excluded from the segment?  I<br>
&gt; think that it makes no difference, and excluding them is only an<br>
&gt; optimization.  The argument is as follows.  Imagine that immediately after<br>
&gt; loading the image segment there is a garbage collection.  That garbage<br>
&gt; collection will collect all the objects in the last category as they are<br>
&gt; only reachable from the weak arrays in the segment.  Hence we are free to<br>
&gt; follow weak references as if they are strong when we create the image<br>
&gt; segment, leaving it to subsequent events to reclaim those objects.<br>
&gt;<br>
&gt; An analogous argument accounts for objects reachable from ephemerons.  Is<br>
&gt; my reasoning sound?<br>
&gt; --<br>
&gt; best,<br>
&gt; Eliot<br>
&gt;<br>
&gt;<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&#39;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>