Hi, I think the problem was not clearly explained. This is the scenario that is problematic.��

This scenario does not happen in the new Spur implementation of forwarding, but I think is happening in the old one.

1. You have, let's say 3 instances of ClassA.

2. You add a new instance variable to ClassA. It produces

�� 2a. A new ClassAv2 is created with the instances variables of ClassA and the newone

�� 2b. 3 Instances of ClassAv2 are created

�� 2c. The values of the instance variables of ClassA are copied to the ones in ClassAv2 (the ones missing are left in nil).

�� 2d. The 3 instances of ClassA are becomed forward to the 3 instances of ClassAv2

�� 2e. The ClassA is becomed forward ClassAv2

3. You add a new instance variable to ClassAv2. It produces

�� 3a. A new ClassAv3 is created with the instances variables of ClassAv2 and the newone

�� 3b. 3 Instances of ClassAv3 are created

�� 3c. The values of the instance variables of ClassAv2 are copied to the ones in ClassAv3 (the ones missing are left in nil).

�� 3d. The 3 instances of ClassAv2 are becomed forward to the 3 instances of ClassAv3

�� 3e. The ClassAv2 is becomedFormeward ClassAv3

4. All the instances of ClassAV3 have the correct format and everything works.

What is the problem:

===============

- When you do the first add instance variable, the old instances (the one from ClassA) which are smaller (has 1 instance variable less)

have its class changed (after you perform a become of ClassA to ClassAv2). So if you try to use them everything will explode, because you will trying to access an instance variable that does not exists.

These instances are not referenced by anyone, however if you perform a ClassAv2>>allInstances you will find them. So if you modify the class adding two variables, one after another the second time��

you will be accessing the invalid instances.

Considering the differences in the Become implementation

============================================

However, the main difference is the implementation of the become forward.��

Let's start with the new implementation, as it has not problems.

When you do a become forward, from object a to b, the primitive replaces the object a with a forwarder to b.��

When this forwarded is accessed the references to it are rewrited.��

If the objects are the same size (not this scenario) the object b replaces object a. It does not produces an error because the old.

In the become forward the old instances are not keeped.

In the old implementation the whole image is scanned, changing the references to the old instances, replacing with references to the new instances.��

The old instances are not removed, just kept there to let the GC do its work.

Again if the objects are the same size there is special behavior.

I hope know the problem is better explained

Cheers,

Pablo

On Fri, Apr 14, 2017 at 10:50 AM, Igor Stasenko <siguctua@gmail.com> wrote:

On 14 April 2017 at 10:19, Stephane Ducasse <stepharo.self@gmail.com> wrote:
But I do not get how doing that would handle the old instances?
Because you want to migrate the old instances.

+1
there are no such thing as 'bad zombies', if they are there, it means you either don't care about migrating data
or again, don't care about doing #becomeForward-ing them properly.
In any case i don't see how GC could help to fix these issues. You either have consistency or don't have it,
and GC cannot do anything magical to fix it.

��
Stef

On Wed, Apr 12, 2017 at 1:26 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2017-04-12 13:17 GMT+02:00 Guillermo Polito <guillermopolito@gmail.com>:
�� 1) each instance of A is becomed into its corresponding instance of A'
�� 2) finally we become class A into A'
�� This step will make that old instances of A now have:
�� - the old format
�� - but point to the new class A

step 1) ensures that there are no instances of class A anymore.
Check following script:
c1 := Class1 new.
c2 := Class2 new.
c1 becomeForward: c2.
Class1 allInstances "=> #()".

And full migration is executed in high priority uninterrupted process to ensure that between 1) and 2) nobody will instantiate Class1��

--
Best regards,
Igor Stasenko.

Pablo Tesone.
tesonep@gmail.com