[Vm-dev] Re: [squeak-dev] Image Segment semantics and weakness

Andres Valloud avalloud at smalltalk.comcastbiz.net
Mon Oct 20 01:23:36 UTC 2014


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.

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?

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.

On 10/19/14 18:01 , Eliot Miranda wrote:
> - /not/ reachable form the system roots, /not/ reachable from the
> segment roots via strong pointers
>
> Should this last category be included or excluded from the segment?  I
> think that it makes no difference, and excluding them is only an
> optimization.  The argument is as follows.  Imagine that immediately
> after loading the image segment there is a garbage collection.  That
> garbage collection will collect all the objects in the last category as
> they are only reachable from the weak arrays in the segment.  Hence we
> are free to follow weak references as if they are strong when we create
> the image segment, leaving it to subsequent events to reclaim those
> objects.
>
> An analogous argument accounts for objects reachable from ephemerons.
> Is my reasoning sound?


More information about the Vm-dev mailing list