[Pharo-project] 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
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.
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 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.
Best,
Mariano _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/21 Daniel P Zepeda <daniel@zepeda.ws>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <daniel@zepeda.ws>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <stephane.ducasse@inria.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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Mariano Martinez Peck Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] over bloated image workaround On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <stephane.ducasse@inria.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 > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Mariano Martinez Peck Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] over bloated image workaround
On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <stephane.ducasse@inria.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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ]En nombre de Mariano Martinez Peck Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] over bloated image workaround
On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <stephane.ducasse@inria.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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+1 On 2009-08-23 10:55:01 -0300, Stéphane Ducasse <stephane.ducasse@inria.fr> 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bou nces@lists.gforge.inria.fr
]En nombre de Mariano Martinez Peck Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. Para: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/23 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ]En nombre de Mariano Martinez Peck Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] over bloated image workaround
On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <stephane.ducasse@inria.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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
+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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] En nombre de Stéphane Ducasse Enviado el: Sunday, August 23, 2009 10:55 Para: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ]En nombre de Mariano Martinez Peck Enviado el: Sábado, 22 de Agosto de 2009 05:53 p.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] over bloated image workaround
On Sat, Aug 22, 2009 at 5:42 AM, Stéphane Ducasse <stephane.ducasse@inria.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 Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
reinitAllCache. resetMap. selectors not found... -----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Mariano Martinez Peck Enviado el: Viernes, 21 de Agosto de 2009 06:25 p.m. Para: Pharo Development Asunto: [Pharo-project] 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
2009/8/22 Carlos Crosetti <carlos@mostar.com.ar>
reinitAllCache. resetMap.
selectors not found...
Did you filein the three files I attached?
-----Mensaje original----- *De:* pharo-project-bounces@lists.gforge.inria.fr [mailto: pharo-project-bounces@lists.gforge.inria.fr]*En nombre de *Mariano Martinez Peck *Enviado el:* Viernes, 21 de Agosto de 2009 06:25 p.m. *Para:* Pharo Development *Asunto:* [Pharo-project] 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Adrian Lienhard -
Carlos Crosetti -
Daniel P Zepeda -
Esteban Lorenzano -
Igor Stasenko -
Mariano Martinez Peck -
Sebastian Sastre -
Stéphane Ducasse