<div dir="ltr">Hi Andreas,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 19, 2014 at 6:23 PM, Andres Valloud <span dir="ltr"><<a href="mailto:avalloud@smalltalk.comcastbiz.net" target="_blank">avalloud@smalltalk.comcastbiz.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
At first glance this sounds ok to me... however, I'd feel better if GC cleaned up the recently loaded segment before anything in the segment can become active or receive a message or be visible elsewhere. If that does not happen, there will be a window of opportunity for really weird stuff to occur.<br></blockquote><div><br></div><div>Oh thats a very good point. I new it was wise to ask :-) I'll sleep on this but at the moment I'm close to being convinced that there either needs to be the equivalent of a GC immediately on loading, or the equivalent of a GC on creating the segment, so as not to include category three objects in the segment. Damn, I suspect that's tricky to implement efficiently ;-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For example, consider what happens if you have an ephemeron reachable from a weak array, the freshly loaded segment turns the weak array into a strong array (not a far fetched example --- this is done in practice for performance), and now you have an ephemeron that can go ahead and do random stuff in finalization. But how would that ephemeron know it is no longer living in the image where it was instantiated?<br>
<br>
Assuming I am still understanding image segments correctly, the more I think about them, the more I start liking loadable modules from declarative specifications --- in that other world, such weird brain surgery stuff is impossible. Nevertheless, I understand you may be in a situation where you have to support existing features.</blockquote><div><br></div><div>Yes, image segments are used heavily in etoys (project saving and loading) and Terf (exchanging behavior and initial state between replicas). So Spur does need to support image segments if it is to be easy to adopt. And that's always been an important criterion for Cog.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/19/14 18:01 , Eliot Miranda wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- /not/ reachable form the system roots, /not/ reachable from the<span class=""><br>
segment 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<br>
after loading the image segment there is a garbage collection. That<br>
garbage collection will collect all the objects in the last category as<br>
they are only reachable from the weak arrays in the segment. Hence we<br>
are free to follow weak references as if they are strong when we create<br>
the image segment, leaving it to subsequent events to reclaim those<br>
objects.<br>
<br>
An analogous argument accounts for objects reachable from ephemerons.<br>
Is my reasoning sound?<br>
</span></blockquote>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>