[Vm-dev] Re: Performance of primitiveFailFor: and use of primFailCode

[Igor Stasenko]

On 25 May 2011 00:51, Craig Latta <craig at netjam.org> wrote:
>
>
> Hi Igor--
>
>> > ...now I'm looking forward to ephemeron conflicts. :)
>> >
>>
>> What conflicts?
>>
>> Please elaborate :)
>
>     Oh, none yet, I just suspect there will be some with the stuff I
> wrote to GC stale methods.

Yes. This could be a problem. Consider a following:

MyClass>>someMethod
  ^ #( 'abc' 'def' )


ephemeron := Ephemeron new
   key: self someMethod first
   value: somethingElse.

So, we created an ephemeron, whose key are object which came from
method's literals. And even worse,
as it shown above, it could be not a direct literal, but nested object.

Now, if you GC this stale #someMethod , it will apparently turn
ephemeron's value to be weakly referenced,
and its key will be lost and replaced by nil.

To circumvent that, you have to make sure that all literals which kept
by method are still reachable from roots by other means.
Another approach is to detect and do something with such problematic
ephemerons, but as example shows, this could be tricky.

Btw this will happen with other weak refs as well.

array := WeakArray with: self someMethod first.

do you have a solution for that?

Of course it depends on your intents.

-- 
Best regards,
Igor Stasenko AKA sig.