allObjectsDo: (was Re: [squeak-dev] The Inbox: System-cwp.662.mcz)

David T. Lewis lewis at mail.msen.com
Sun Jan 12 19:42:38 UTC 2014


On Sun, Jan 12, 2014 at 02:02:08PM -0500, Colin Putney wrote:
> On Sun, Jan 12, 2014 at 1:45 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
> 
> > Say you want to wrap every object in the system in a proxy.
> > You would need to use #allObjectsDo:. but when we enumerate all
> > object, the new ones too, we end up having proxies for proxies for
> > proxies ad infinitum (endless non-loop?) and we can?t know it?
> >
> 
> Yeah, that's an example of creating objects faster than we can enumerate
> them. (Or, exactly as fast as we can enumerate them, I suppose). It
> wouldn't have worked pre-closures, either.
> 
> The consensus so far is that we like the safety of a sentinel object, as it
> lets us do whatever we want within the loop, and potentially not seeing all
> the objects in the image is an acceptable trade-off for that safety. Fair
> enough.
> 

(Changing subject line because original discussion spans commit notices)

The most recent inbox entry System-cwp.663 seems to work fine on an
interpreter VM.

For my understanding, can you clarify, with respect to the original concern
that involves MC proxies - does the problem occur with the interpreter VM
as well as Cog, or was it specific to one kind of VM?

It is worth noting that allObjectsDo: relies on assumptions about how
the objects memory works internally. It requires that #someObject will
always answer the object at the lowest address in the object memory, and
also that a newly allocated object will always be placed at a higher
address location than all other objects. Either of these assumptions is
likely to be a problem as new and better object memories and garbage
collectors are implemented.

Dave



More information about the Squeak-dev mailing list