<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11.01.2013 20:14, Eliot Miranda
wrote:<br>
</div>
<blockquote
cite="mid:CAC20JE22K+pU3gjp+pFM_n4ALYpbkYXFU5-roOE2+tYyynP3Bw@mail.gmail.com"
type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<div dir="ltr">Hi All,
<div><br>
</div>
<div> there's an interesting issue with becomeForward: that's
raised by the Newspeak implementation. Its AtomicInstaller,
the equivalent of ClassBuilder that mutates existing instances
when classes are redefined, uses forwardBecome: to map old
instances to new instances. But it uses allInstances
subsequently to collect the modified instances a second time.
Since becomeForward: currently simply manipulates references,
the old instances no longer referenced after becomeForward:
can still be found by allInstances, and this causes a bug in
AtomicInstaller, which is worked-around by running the GC
immediately after the forwardBecome:.</div>
</div>
</blockquote>
Don't think that's a problem unique to Newspeak, if the comment at
the bottom of ClassBuilder>>update:to: is to be trusted :)<br>
<blockquote
cite="mid:CAC20JE22K+pU3gjp+pFM_n4ALYpbkYXFU5-roOE2+tYyynP3Bw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Gilad Bracha's desire is for becomeForward: to eliminate
the objects whose references are replaced. My initial
reaction was to say don't redefine becomeForward: by requiring
it to run a GC; the existing primitives are useful as defined
and a more complex operation that also eliminates objects
rather than just replacing references can be defined by
composition. But that's because I'm stupid.<br clear="all">
<div><br>
</div>
<div>It strikes me that its really easy in the current GC for
becomeForward: to mark the objects in the second array, the
objects whose references are eliminated, such that they
would not be discovered via allInstances or allObjects. In
the Squeak GC the objects are merely freed. My concern is
with some future GC. I'm fairly confident that the same
could be implemented in any GC; that one can enumerate a
given set of objects without running a full GC and mark each
object such that it is effectively removed from the heap,
prior to running the GC, and that the space occupied will be
reclaimed at some later time.</div>
<div><br>
</div>
<div>So I have two questions.</div>
<div><br>
</div>
<div>1. anyone think of a convincing counterexample of a GC
in which that wouldn't be possible?</div>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAC20JE22K+pU3gjp+pFM_n4ALYpbkYXFU5-roOE2+tYyynP3Bw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div><br>
</div>
<div>2. anyone have an opinion or argument either way that
becomeForward: should free the objects whose references it
destroys instead of merely destroying those references?</div>
-- <br>
TIA,
<div>Eliot</div>
</div>
</div>
</blockquote>
Can't think of anything for 1, barring any bugs marking active
objects as freed of course.<br>
Which isn't very likely, as long as one doesn't introduce a
destroy() primitive, but keep the transition to free status an
internal detail of the vm.<br>
Out of curiosity, are there other places than becomeForward: this is
applicable? <br>
<br>
For 2, I agree with becomeForward: "freeing" the forwarded objects.
<br>
I don't quite see the value in the preferred method from the comment
other than that it *could* be implemented in the image (creating
copy of class before forwarding that, and change class of forwarded
instances to that) , it just sounds like a lot of work for no real
benefit considering the whole point is to avoid the instances being
referrable afterwards.<br>
Not to mention, that would only help in the specific
ClassBuilder/AtomicInstaller case, and not in a general
becomeForward -> allInstances scenario.<br>
<br>
Cheers,<br>
Henry<br>
</body>
</html>