Hi, I just submitted and integrated a fix for the leak problem. That should fix the problem we are having in Pharo3... now we need to work on a backport for Pharo2... any takers? :) Esteban
Le 19/09/2013 17:20, Esteban Lorenzano a écrit :
Hi,
I just submitted and integrated a fix for the leak problem. That should fix the problem we are having in Pharo3... now we need to work on a backport for Pharo2... any takers? :)
I need some explanations :) Thierry
Esteban
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
From what I understand:
- on: do: register the block context as the receiver to kick in the block evaluation => weak registration is then not weak anymore - there was an old LegacyRegistrationMechanism that works (fallback for old VM that do not have the right way of managing weak structure) and the LegacyRegistration got some on:do: and grew grew grew. Stef On Sep 19, 2013, at 5:30 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 19/09/2013 17:20, Esteban Lorenzano a écrit :
Hi,
I just submitted and integrated a fix for the leak problem. That should fix the problem we are having in Pharo3... now we need to work on a backport for Pharo2... any takers? :)
I need some explanations :)
Thierry
Esteban
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Ok. I've looked at the first slice (step 1/2 of 3 :)) and it seems doable. But I don't think I'll be able to do step 2 and 3 :( Thierry Le 19/09/2013 17:26, Stéphane Ducasse a écrit :
From what I understand:
- on: do: register the block context as the receiver to kick in the block evaluation => weak registration is then not weak anymore
- there was an old LegacyRegistrationMechanism that works (fallback for old VM that do not have the right way of managing weak structure) and the LegacyRegistration got some on:do: and grew grew grew.
Stef
On Sep 19, 2013, at 5:30 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 19/09/2013 17:20, Esteban Lorenzano a écrit :
Hi,
I just submitted and integrated a fix for the leak problem. That should fix the problem we are having in Pharo3... now we need to work on a backport for Pharo2... any takers? :)
I need some explanations :)
Thierry
Esteban
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
is a really annoying combination of problems: 1) the abuse of on:do: for register announcers, usually in SystemAnnouncer singleton, who then register immortal announcements. 2) the abuse of weak message in places where is not needed (like in non global announcements who then will be collected when owner collected) 3) a weird case when instead a WeakAnnouncementSubscription, system was registering LegacyWeakSubscription, and this one uses WeakRegistry (which is a singleton too)... so, if combined with #on:do:, the subscriptions were becoming immortal too. So far, we think that is all the problem. You need two steps (the 3rd was because I forgot to commit something :p) because after changing somethign in the finalization process, you then need to restart it to be able to remove old/not used methods. cheers, Esteban On Sep 19, 2013, at 5:30 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 19/09/2013 17:20, Esteban Lorenzano a écrit :
Hi,
I just submitted and integrated a fix for the leak problem. That should fix the problem we are having in Pharo3... now we need to work on a backport for Pharo2... any takers? :)
I need some explanations :)
Thierry
Esteban
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Good news... I saw that Seaside 3.x was okay with Pharo 3. I am starting a new project. Should I start with Pharo3 right away? Phil On Thu, Sep 19, 2013 at 5:33 PM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
is a really annoying combination of problems:
1) the abuse of on:do: for register announcers, usually in SystemAnnouncer singleton, who then register immortal announcements. 2) the abuse of weak message in places where is not needed (like in non global announcements who then will be collected when owner collected) 3) a weird case when instead a WeakAnnouncementSubscription, system was registering LegacyWeakSubscription, and this one uses WeakRegistry (which is a singleton too)... so, if combined with #on:do:, the subscriptions were becoming immortal too.
So far, we think that is all the problem.
You need two steps (the 3rd was because I forgot to commit something :p) because after changing somethign in the finalization process, you then need to restart it to be able to remove old/not used methods.
cheers, Esteban
On Sep 19, 2013, at 5:30 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 19/09/2013 17:20, Esteban Lorenzano a écrit :
Hi,
I just submitted and integrated a fix for the leak problem. That should fix the problem we are having in Pharo3... now we need to
work on a backport for Pharo2... any takers? :)
I need some explanations :)
Thierry
Esteban
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Good news...
I saw that Seaside 3.x was okay with Pharo 3.
I am starting a new project. Should I start with Pharo3 right away?
We are trying not to break code but it can happen. So you can be always a bit behind cutting edge. Stef
is a really annoying combination of problems:
1) the abuse of on:do: for register announcers, usually in SystemAnnouncer singleton, who then register immortal announcements. 2) the abuse of weak message in places where is not needed (like in non global announcements who then will be collected when owner collected) 3) a weird case when instead a WeakAnnouncementSubscription, system was registering LegacyWeakSubscription, and this one uses WeakRegistry (which is a singleton too)... so, if combined with #on:do:, the subscriptions were becoming immortal too.
So far, we think that is all the problem.
You need two steps (the 3rd was because I forgot to commit something :p) because after changing somethign in the finalization process, you then need to restart it to be able to remove old/not used methods.
cheers, Esteban
On Sep 19, 2013, at 5:30 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 19/09/2013 17:20, Esteban Lorenzano a écrit :
Hi,
I just submitted and integrated a fix for the leak problem. That should fix the problem we are having in Pharo3... now we need to work on a backport for Pharo2... any takers? :)
I need some explanations :)
Thierry
Esteban
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Ok, I've added issue 11639 for the backport. I'll make a try tonight. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : jeudi 19 septembre 2013 17:33 Ã : Pharo Development List Objet : Re: [Pharo-dev] about the memory leak in Pharo2/Pharo3 is a really annoying combination of problems: 1) the abuse of on:do: for register announcers, usually in SystemAnnouncer singleton, who then register immortal announcements. 2) the abuse of weak message in places where is not needed (like in non global announcements who then will be collected when owner collected) 3) a weird case when instead a WeakAnnouncementSubscription, system was registering LegacyWeakSubscription, and this one uses WeakRegistry (which is a singleton too)... so, if combined with #on:do:, the subscriptions were becoming immortal too. So far, we think that is all the problem. You need two steps (the 3rd was because I forgot to commit something :p) because after changing somethign in the finalization process, you then need to restart it to be able to remove old/not used methods. cheers, Esteban On Sep 19, 2013, at 5:30 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 19/09/2013 17:20, Esteban Lorenzano a écrit :
Hi,
I just submitted and integrated a fix for the leak problem. That should fix the problem we are having in Pharo3... now we need to work on a backport for Pharo2... any takers? :)
I need some explanations :)
Thierry
Esteban
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
thanks It will help us. We got some internal reorganisation right now because fernando is leaving the team. stef On Sep 19, 2013, at 10:42 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Ok, I've added issue 11639 for the backport.
I'll make a try tonight.
Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : jeudi 19 septembre 2013 17:33 Ã : Pharo Development List Objet : Re: [Pharo-dev] about the memory leak in Pharo2/Pharo3
is a really annoying combination of problems:
1) the abuse of on:do: for register announcers, usually in SystemAnnouncer singleton, who then register immortal announcements. 2) the abuse of weak message in places where is not needed (like in non global announcements who then will be collected when owner collected) 3) a weird case when instead a WeakAnnouncementSubscription, system was registering LegacyWeakSubscription, and this one uses WeakRegistry (which is a singleton too)... so, if combined with #on:do:, the subscriptions were becoming immortal too.
So far, we think that is all the problem.
You need two steps (the 3rd was because I forgot to commit something :p) because after changing somethign in the finalization process, you then need to restart it to be able to remove old/not used methods.
cheers, Esteban
On Sep 19, 2013, at 5:30 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 19/09/2013 17:20, Esteban Lorenzano a écrit :
Hi,
I just submitted and integrated a fix for the leak problem. That should fix the problem we are having in Pharo3... now we need to work on a backport for Pharo2... any takers? :)
I need some explanations :)
Thierry
Esteban
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
participants (5)
-
Esteban Lorenzano -
GOUBIER Thierry -
Goubier Thierry
-
phil＠highoctane.be -
Stéphane Ducasse