over bloated image workaround
Locked
over bloated image workaround
 
|
Hi folks: Sometimes, my Pharo images grows a lot.
Size like 80MB or similar. Marcelo Cortez gave me a couple of changes
(fileouts) that make my images go back to their original size or
similar. For example, it was tasted in a 87 MB and after this changes
and this stuff, it become in 24 MB. The same with another one from 65M
to 35M.
If you have a big Pharo image, save a copy and do this tests: 1) File in all the changes I attach. 2) Go to a workspace and evaluate: OBDPAbstract reinitAllCache. LocalSends allInstances first initialize. EventManager resetMap. Smalltalk garbageCollect. Did this make your image too much smaller? When I evaluate SystemNavigation default obsoleteBehavio size I get a a number of 3 digits. Perhaps it is a matter with the OB. I guess it generates dependences while you are developing a class and it creates on the fly an obsolteClassXXX when there is something that doesn't exist. Then they are processes and they are never garbage collected. When SmalltalkImage tries to fix the obsoletes delegates to the literal frames of the compiled methods so that to search references to the obsoletes. But references were not gone because they weren't garbage collected. The same method finishes with error if the obsoletes > 0. Does anyone has a comment for this? I tried to do my best to write in English from what Marcelo told me and from what I can understand from the changesets. Best, Mariano _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
On Aug 21, 2009, at 4:25 PM, Mariano Martinez Peck wrote: Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or similar. Marcelo Cortez gave me a couple of changes (fileouts) that make my images go back to their original size or similar. For example, it was tasted in a 87 MB and after this changes and this stuff, it become in 24 MB. The same with another one from 65M to 35M.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
2009/8/21 Daniel P Zepeda <[hidden email]>
Ups...sorry. I attach it here.
I think the same as you.
Excellent and thanks for the report
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project  EventManager class-resetMap.st (310 bytes) Download Attachment OBDPAbstract class-reinitAllCache.st (614 bytes) Download Attachment OBDPAbstract class-reinitCache.st (590 bytes) Download Attachment |
Re: over bloated image workaround
|
|
Hi Mariano
As a first step, I suggest to find out which of the three caches actually is the one that uses all that memory. In a large image, you can run one of the cleanups at a time, and after each one do a GC and check the memory consumption (compare the free memory of: SmalltalkImage current vmStatisticsReportString) HTH, Adrian On Aug 22, 2009, at 03:15 , Mariano Martinez Peck wrote: > 2009/8/21 Daniel P Zepeda <[hidden email]> > >> >> On Aug 21, 2009, at 4:25 PM, Mariano Martinez Peck wrote: >> >> Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or >> similar. Marcelo Cortez gave me a couple of changes (fileouts) that >> make my >> images go back to their original size or similar. For example, it >> was tasted >> in a 87 MB and after this changes and this stuff, it become in 24 >> MB. The >> same with another one from 65M to 35M. >> >> If you have a big Pharo image, save a copy and do this tests: >> >> 1) File in all the changes I attach. >> >> >> There is nothing attached. >> > > > Ups...sorry. I attach it here. > > > >> >> >> 2) Go to a workspace and evaluate: >> >> OBDPAbstract reinitAllCache. >> LocalSends allInstances first initialize. >> EventManager resetMap. >> Smalltalk garbageCollect. >> >> Did this make your image too much smaller? >> >> When I evaluate SystemNavigation default obsoleteBehavio size I >> get a a >> number of 3 digits. >> >> Perhaps it is a matter with the OB. I guess it generates >> dependences while >> you are developing a class and it creates on the fly an >> obsolteClassXXX when >> there is something that doesn't exist. Then they are processes and >> they are >> never garbage collected. >> >> When SmalltalkImage tries to fix the obsoletes delegates to the >> literal >> frames of the compiled methods so that to search references to the >> obsoletes. But references were not gone because they weren't garbage >> collected. The same method finishes with error if the obsoletes > 0. >> >> Does anyone has a comment for this? >> >> >> Well, the only comment I have is that this procedure should go on the >> snippets page no the Pharo Project website. I know you are after a >> deeper >> fix, but others will have to provide that, as this is way over my >> head at >> this time. >> > > I think the same as you. > > >> >> >> >> I tried to do my best to write in English from what Marcelo told me >> and >> from what I can understand from the changesets. >> >> >> You did a good job, I understand the problem conceptually from your >> description. I just don't have any idea how to fix that. >> > > Excellent and thanks for the report > > >> >> >> >> Best, >> >> Mariano _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > <EventManager class-resetMap.st><OBDPAbstract class- > reinitAllCache.st><OBDPAbstract class- > reinitCache.st>_______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
In reply to this post by Mariano Martinez Peck
We should check that.
Can you open a ticket? Stef On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: > Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or > similar. Marcelo Cortez gave me a couple of changes (fileouts) that > make my images go back to their original size or similar. For > example, it was tasted in a 87 MB and after this changes and this > stuff, it become in 24 MB. The same with another one from 65M to 35M. > > If you have a big Pharo image, save a copy and do this tests: > > 1) File in all the changes I attach. > 2) Go to a workspace and evaluate: > > OBDPAbstract reinitAllCache. > LocalSends allInstances first initialize. > EventManager resetMap. > Smalltalk garbageCollect. > > Did this make your image too much smaller? > > When I evaluate SystemNavigation default obsoleteBehavio size I > get a a number of 3 digits. > > Perhaps it is a matter with the OB. I guess it generates dependences > while you are developing a class and it creates on the fly an > obsolteClassXXX when there is something that doesn't exist. Then > they are processes and they are never garbage collected. > > When SmalltalkImage tries to fix the obsoletes delegates to the > literal frames of the compiled methods so that to search references > to the obsoletes. But references were not gone because they weren't > garbage collected. The same method finishes with error if the > obsoletes > 0. > > Does anyone has a comment for this? > > I tried to do my best to write in English from what Marcelo told me > and from what I can understand from the changesets. > > Best, > > Mariano _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
In reply to this post by Mariano Martinez Peck
reinitAllCache.
resetMap.
selectors not found...
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
2009/8/22 Carlos Crosetti <[hidden email]>
Did you filein the three files I attached?
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
In reply to this post by Stéphane Ducasse
On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <[hidden email]> wrote: We should check that.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
Mariano, Ivery value those scripts!
My
image is small, but anyway I couldn't resist the challenge and tried so far,
I got
my image shrunk down from 20.7mb to 18.2mb.
This
is probably a candidate for extending something I may
call
"the Pharo equivalent to VW Runtime Packager" - I am not so familiar to
Pharo to know
if
such a feature exist.
Regards, Carlos
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
On Aug 23, 2009, at 03:14 , Carlos Crosetti wrote:
> Mariano, Ivery value those scripts! > > My image is small, but anyway I couldn't resist the challenge and > tried so > far, > I got my image shrunk down from 20.7mb to 18.2mb. > > This is probably a candidate for extending something I may > call "the Pharo equivalent to VW Runtime Packager" - I am not so > familiar to > Pharo to know > if such a feature exist. Yes, see ScriptLoader>>cleanUpForRelease and >>cleanUpForProduction. It doesn't clean up OB caches though, since I wrote these scripts for Pharo-core. Cheers, Adrian > > Regards, Carlos > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]]En nombre de > Mariano > Martinez Peck > Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. > Para: [hidden email] > Asunto: Re: [Pharo-project] over bloated image workaround > > > > > > On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse > <[hidden email]> wrote: > > We should check that. > Can you open a ticket? > > > Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 > > > > > > Stef > > On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: > >> Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or >> similar. Marcelo Cortez gave me a couple of changes (fileouts) that >> make my images go back to their original size or similar. For >> example, it was tasted in a 87 MB and after this changes and this >> stuff, it become in 24 MB. The same with another one from 65M to 35M. >> >> If you have a big Pharo image, save a copy and do this tests: >> >> 1) File in all the changes I attach. >> 2) Go to a workspace and evaluate: >> >> OBDPAbstract reinitAllCache. >> LocalSends allInstances first initialize. >> EventManager resetMap. >> Smalltalk garbageCollect. >> >> Did this make your image too much smaller? >> >> When I evaluate SystemNavigation default obsoleteBehavio size I >> get a a number of 3 digits. >> >> Perhaps it is a matter with the OB. I guess it generates dependences >> while you are developing a class and it creates on the fly an >> obsolteClassXXX when there is something that doesn't exist. Then >> they are processes and they are never garbage collected. >> >> When SmalltalkImage tries to fix the obsoletes delegates to the >> literal frames of the compiled methods so that to search references >> to the obsoletes. But references were not gone because they weren't >> garbage collected. The same method finishes with error if the >> obsoletes > 0. >> >> Does anyone has a comment for this? >> >> I tried to do my best to write in English from what Marcelo told me >> and from what I can understand from the changesets. >> >> Best, >> > >> Mariano _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
In reply to this post by Carlos Crosetti-4
the goal of pharo is also to avoid VW runtime packager (because the
package tries to statically find how to reduce image size which is ***really*** difficult in a dynamic language. Now Pavel got a 2mb image based on pharo: I imagine that we will be able to start from this one to build up pharo in the future :) On Aug 23, 2009, at 3:14 AM, Carlos Crosetti wrote: > Mariano, Ivery value those scripts! > > My image is small, but anyway I couldn't resist the challenge and > tried so far, > I got my image shrunk down from 20.7mb to 18.2mb. > > This is probably a candidate for extending something I may > call "the Pharo equivalent to VW Runtime Packager" - I am not so > familiar to Pharo to know > if such a feature exist. > > Regards, Carlos > -----Mensaje original----- > De: [hidden email] [mailto:[hidden email] > ]En nombre de Mariano Martinez Peck > Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. > Para: [hidden email] > Asunto: Re: [Pharo-project] over bloated image workaround > > > > On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <[hidden email] > > wrote: > We should check that. > Can you open a ticket? > > > Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 > > > > > Stef > On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: > > > Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or > > similar. Marcelo Cortez gave me a couple of changes (fileouts) that > > make my images go back to their original size or similar. For > > example, it was tasted in a 87 MB and after this changes and this > > stuff, it become in 24 MB. The same with another one from 65M to > 35M. > > > > If you have a big Pharo image, save a copy and do this tests: > > > > 1) File in all the changes I attach. > > 2) Go to a workspace and evaluate: > > > > OBDPAbstract reinitAllCache. > > LocalSends allInstances first initialize. > > EventManager resetMap. > > Smalltalk garbageCollect. > > > > Did this make your image too much smaller? > > > > When I evaluate SystemNavigation default obsoleteBehavio size I > > get a a number of 3 digits. > > > > Perhaps it is a matter with the OB. I guess it generates dependences > > while you are developing a class and it creates on the fly an > > obsolteClassXXX when there is something that doesn't exist. Then > > they are processes and they are never garbage collected. > > > > When SmalltalkImage tries to fix the obsoletes delegates to the > > literal frames of the compiled methods so that to search references > > to the obsoletes. But references were not gone because they weren't > > garbage collected. The same method finishes with error if the > > obsoletes > 0. > > > > Does anyone has a comment for this? > > > > I tried to do my best to write in English from what Marcelo told me > > and from what I can understand from the changesets. > > > > Best, > > > > Mariano _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
+1
On 2009-08-23 10:55:01 -0300, Stéphane Ducasse <[hidden email]> said: > the goal of pharo is also to avoid VW runtime packager (because the > > package tries to statically find how to reduce > image size which is ***really*** difficult in a dynamic language. > Now Pavel got a 2mb image based on pharo: I imagine that we will be > > able to start from this one to build up > pharo in the future :) > > > On Aug 23, 2009, at 3:14 AM, Carlos Crosetti wrote: > >> Mariano, Ivery value those scripts! >> >> My image is small, but anyway I couldn't resist the challenge and > >> tried so far, >> I got my image shrunk down from 20.7mb to 18.2mb. >> >> This is probably a candidate for extending something I may >> call "the Pharo equivalent to VW Runtime Packager" - I am not so > >> familiar to Pharo to know >> if such a feature exist. >> >> Regards, Carlos >> -----Mensaje original----- >> De: >> [hidden email] >> [mailto:pharo-project-bou > [hidden email] > >> ]En nombre de Mariano Martinez Peck >> Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. >> Para: [hidden email] >> Asunto: Re: [Pharo-project] over bloated image workaround >> >> >> >> On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <stephane.ducasse@inr > ia.fr > >>> wrote: >> We should check that. >> Can you open a ticket? >> >> >> Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 >> >> >> >> >> Stef >> On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: >> >>> Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or >>> similar. Marcelo Cortez gave me a couple of changes (fileouts) that >>> make my images go back to their original size or similar. For >>> example, it was tasted in a 87 MB and after this changes and this >>> stuff, it become in 24 MB. The same with another one from 65M to > >> 35M. >>> >>> If you have a big Pharo image, save a copy and do this tests: >>> >>> 1) File in all the changes I attach. >>> 2) Go to a workspace and evaluate: >>> >>> OBDPAbstract reinitAllCache. >>> LocalSends allInstances first initialize. >>> EventManager resetMap. >>> Smalltalk garbageCollect. >>> >>> Did this make your image too much smaller? >>> >>> When I evaluate SystemNavigation default obsoleteBehavio size I >>> get a a number of 3 digits. >>> >>> Perhaps it is a matter with the OB. I guess it generates dependences >>> while you are developing a class and it creates on the fly an >>> obsolteClassXXX when there is something that doesn't exist. Then >>> they are processes and they are never garbage collected. >>> >>> When SmalltalkImage tries to fix the obsoletes delegates to the >>> literal frames of the compiled methods so that to search references >>> to the obsoletes. But references were not gone because they weren't >>> garbage collected. The same method finishes with error if the >>> obsoletes > 0. >>> >>> Does anyone has a comment for this? >>> >>> I tried to do my best to write in English from what Marcelo told me >>> and from what I can understand from the changesets. >>> >>> Best, >>> >>> Mariano _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
In reply to this post by Stéphane Ducasse
2009/8/23 Stéphane Ducasse <[hidden email]>:
> the goal of pharo is also to avoid VW runtime packager (because the > package tries to statically find how to reduce > image size which is ***really*** difficult in a dynamic language. > Now Pavel got a 2mb image based on pharo: I imagine that we will be > able to start from this one to build up > pharo in the future :) > > 2mb is very very good size, especially for embedded solutions. > On Aug 23, 2009, at 3:14 AM, Carlos Crosetti wrote: > >> Mariano, Ivery value those scripts! >> >> My image is small, but anyway I couldn't resist the challenge and >> tried so far, >> I got my image shrunk down from 20.7mb to 18.2mb. >> >> This is probably a candidate for extending something I may >> call "the Pharo equivalent to VW Runtime Packager" - I am not so >> familiar to Pharo to know >> if such a feature exist. >> >> Regards, Carlos >> -----Mensaje original----- >> De: [hidden email] [mailto:[hidden email] >> ]En nombre de Mariano Martinez Peck >> Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. >> Para: [hidden email] >> Asunto: Re: [Pharo-project] over bloated image workaround >> >> >> >> On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <[hidden email] >> > wrote: >> We should check that. >> Can you open a ticket? >> >> >> Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 >> >> >> >> >> Stef >> On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: >> >> > Hi folks: Sometimes, my Pharo images grows a lot. Size like 80MB or >> > similar. Marcelo Cortez gave me a couple of changes (fileouts) that >> > make my images go back to their original size or similar. For >> > example, it was tasted in a 87 MB and after this changes and this >> > stuff, it become in 24 MB. The same with another one from 65M to >> 35M. >> > >> > If you have a big Pharo image, save a copy and do this tests: >> > >> > 1) File in all the changes I attach. >> > 2) Go to a workspace and evaluate: >> > >> > OBDPAbstract reinitAllCache. >> > LocalSends allInstances first initialize. >> > EventManager resetMap. >> > Smalltalk garbageCollect. >> > >> > Did this make your image too much smaller? >> > >> > When I evaluate SystemNavigation default obsoleteBehavio size I >> > get a a number of 3 digits. >> > >> > Perhaps it is a matter with the OB. I guess it generates dependences >> > while you are developing a class and it creates on the fly an >> > obsolteClassXXX when there is something that doesn't exist. Then >> > they are processes and they are never garbage collected. >> > >> > When SmalltalkImage tries to fix the obsoletes delegates to the >> > literal frames of the compiled methods so that to search references >> > to the obsoletes. But references were not gone because they weren't >> > garbage collected. The same method finishes with error if the >> > obsoletes > 0. >> > >> > Does anyone has a comment for this? >> > >> > I tried to do my best to write in English from what Marcelo told me >> > and from what I can understand from the changesets. >> > >> > Best, >> > >> > Mariano _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: over bloated image workaround
|
|
In reply to this post by Stéphane Ducasse
+1
Stripping or packaging an image is an unguaranteed process by design. Writing software is mostly a declarative job. So, I'd very much prefer to re-load all my declared stuff in a fresh image than make a development image to pass trhough a process that could inject bugs. cheers, sebastian > -----Mensaje original----- > De: [hidden email] > [mailto:[hidden email]] En > nombre de Stéphane Ducasse > Enviado el: Sunday, August 23, 2009 10:55 > Para: [hidden email] > Asunto: Re: [Pharo-project] over bloated image workaround > > the goal of pharo is also to avoid VW runtime packager (because the > package tries to statically find how to reduce > image size which is ***really*** difficult in a dynamic language. > Now Pavel got a 2mb image based on pharo: I imagine that we will be > able to start from this one to build up > pharo in the future :) > > > On Aug 23, 2009, at 3:14 AM, Carlos Crosetti wrote: > > > Mariano, Ivery value those scripts! > > > > My image is small, but anyway I couldn't resist the challenge and > > tried so far, > > I got my image shrunk down from 20.7mb to 18.2mb. > > > > This is probably a candidate for extending something I may > > call "the Pharo equivalent to VW Runtime Packager" - I am not so > > familiar to Pharo to know > > if such a feature exist. > > > > Regards, Carlos > > -----Mensaje original----- > > De: [hidden email] > [mailto:[hidden email] > > ]En nombre de Mariano Martinez Peck > > Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. > > Para: [hidden email] > > Asunto: Re: [Pharo-project] over bloated image workaround > > > > > > > > On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse > <[hidden email] > > > wrote: > > We should check that. > > Can you open a ticket? > > > > > > Ok, done: http://code.google.com/p/pharo/issues/detail?id=1083 > > > > > > > > > > Stef > > On Aug 21, 2009, at 11:25 PM, Mariano Martinez Peck wrote: > > > > > Hi folks: Sometimes, my Pharo images grows a lot. Size > like 80MB or > > > similar. Marcelo Cortez gave me a couple of changes > (fileouts) that > > > make my images go back to their original size or similar. For > > > example, it was tasted in a 87 MB and after this changes and this > > > stuff, it become in 24 MB. The same with another one from 65M to > > 35M. > > > > > > If you have a big Pharo image, save a copy and do this tests: > > > > > > 1) File in all the changes I attach. > > > 2) Go to a workspace and evaluate: > > > > > > OBDPAbstract reinitAllCache. > > > LocalSends allInstances first initialize. > > > EventManager resetMap. > > > Smalltalk garbageCollect. > > > > > > Did this make your image too much smaller? > > > > > > When I evaluate SystemNavigation default obsoleteBehavio size I > > > get a a number of 3 digits. > > > > > > Perhaps it is a matter with the OB. I guess it generates > dependences > > > while you are developing a class and it creates on the fly an > > > obsolteClassXXX when there is something that doesn't exist. Then > > > they are processes and they are never garbage collected. > > > > > > When SmalltalkImage tries to fix the obsoletes delegates to the > > > literal frames of the compiled methods so that to search > references > > > to the obsoletes. But references were not gone because > they weren't > > > garbage collected. The same method finishes with error if the > > > obsoletes > 0. > > > > > > Does anyone has a comment for this? > > > > > > I tried to do my best to write in English from what > Marcelo told me > > > and from what I can understand from the changesets. > > > > > > Best, > > > > > > Mariano _______________________________________________ > > > Pharo-project mailing list > > > [hidden email] > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |