[Vm-dev] pinning GC
squeak-vm-dev at vimes.worldonline.co.uk
Wed Jan 12 09:59:56 UTC 2011
Aren't named ivars only accessed by methods of the receiver? Or does
Squeak use access sends similar to Strongtalk?
In the former case a check to the topmost frame of each Process' stack,
and a check for corpsed objects on each method return should be enough, no?
In the latter case the class in the inline cache will differ, giving an
opportunity in the lookup to fixup the original. One might also check
the corpse bit in ivar accesses to allow an opportunity to replace
corpsed references ahead of a full GC.
The only case where I think this might still be a problem is when Cog
does method inlining and has inlined access sends, though even here it
would presumably have a type test ahead of the inlined code which the
corpse would fail because of the changed class, triggering an uncommon
branch or falling back to a traditional non-lined send (depending on the
approach Cog uses - I haven't looked at the code). Both of which give an
opportunity to handle the corpsed reference, so maybe there won't be a
problem here either.
I think you can also use this for two-way become by cloning both
objects, marking each as a corpse and having each corpse refer to the
clone of the other.
On 12/01/2011 09:37, Josh Gargus wrote:
> On Jan 11, 2011, at 11:48 PM, Igor Stasenko wrote:
>> Eliot, one thing about 'forwarded' objects, which you calling the
>> forwarding corpse is that it can be used not only for pinning,
>> but also with #becomeForward primitive, making it work a lot faster,
>> since its not require to scan whole heap to update references,
>> and update can be done during GC.
>> The only problem, as you pointed out, is the objects which don't have
>> enough space for forwarding pointer. But for this case, i think the
>> primitive can fall back and use old slow scheme.
> I was thinking the same thing. But wouldn't there remain the problem that Eliot mentioned about objects with named variables?
You can follow me on twitter at http://twitter.com/smalltalkhacker
More information about the Vm-dev