[Pharo-project] why are Bitmaps instanciated even in headless mode?
I took a dev image, and run them in two ways: the normal and headless. For each I did a: "Smalltalk garbageCollect. SpaceTally new printSpaceAnalysis" Normal one: Class code space # instances inst space percent Bitmap 3753 133 11099904 37.4 ByteString 2515 85110 6106378 20.6 CompiledMethod 19130 59452 3703463 12.5 Array 2176 77579 2561928 8.6 ...... Headless: Class code space # instances inst space percent ByteString 2515 85110 6106378 24.7 Bitmap 3753 126 6049208 24.5 CompiledMethod 19130 59452 3703463 15.0 Array 2176 77577 2561844 10.4 ...... So....even in headless mode, I have 133 instances of Bitmap, representing 24.5% of the memory.... Ok, 24.5 is better than 37.5, but I don't understand why Bitmap instances are created. Why they are needed ? is there a way to garbageCollect them? thanks Mariano
Well, my 1.1 dev image has: Class code space # instances inst space percent Bitmap 3753 8906 19427212 31.9 ByteString 2515 190202 17459895 28.6 Array 2176 137567 5198744 8.5 CompiledMethod 19130 79223 4888481 8.0 ByteSymbol 1062 52650 1330679 2.2 MethodDictionary 2135 9854 1302376 2.1 MCVersionInfo 1313 22841 913640 1.5 Association 710 74216 890592 1.5 Character 6355 66219 794628 1.3 DateAndTime 7893 28026 672624 1.1 ByteArray 3458 640 639048 1.0 While my 1.1. deploy image (incl Seaside 3 and Glorp) has: CompiledMethod 18784 53888 3082849 20.7 Bitmap 3753 184 2837256 19.0 ByteString 2515 47865 2713211 18.2 Array 2176 45399 2277268 15.3 ByteSymbol 1062 37522 925078 6.2 Character 6355 66219 794628 5.3 MethodDictionary 2135 6296 468456 3.1 WeakArray 718 127 324104 2.2 Association 710 23189 278268 1.9 ByteArray 3370 341 213357 1.4 ClassOrganizer 1326 6112 195584 1.3 Metaclass 3909 3078 123120 0.8 This reduction is done by ScriptLoader>>#cleanUpForRelease (after deleting all unit test packages). HTH, Sven On 24 Aug 2010, at 14:18, Mariano Martinez Peck wrote:
I took a dev image, and run them in two ways: the normal and headless. For each I did a:
"Smalltalk garbageCollect. SpaceTally new printSpaceAnalysis"
Normal one:
Class code space # instances inst space percent Bitmap 3753 133 11099904 37.4 ByteString 2515 85110 6106378 20.6 CompiledMethod 19130 59452 3703463 12.5 Array 2176 77579 2561928 8.6 ......
Headless:
Class code space # instances inst space percent ByteString 2515 85110 6106378 24.7 Bitmap 3753 126 6049208 24.5 CompiledMethod 19130 59452 3703463 15.0 Array 2176 77577 2561844 10.4 ......
So....even in headless mode, I have 133 instances of Bitmap, representing 24.5% of the memory.... Ok, 24.5 is better than 37.5, but I don't understand why Bitmap instances are created. Why they are needed ? is there a way to garbageCollect them?
thanks
Mariano _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/24 Sven Van Caekenberghe <sven@beta9.be>
Well, my 1.1 dev image has:
Class code space # instances inst space percent Bitmap 3753 8906 19427212 31.9 ByteString 2515 190202 17459895 28.6 Array 2176 137567 5198744 8.5 CompiledMethod 19130 79223 4888481 8.0 ByteSymbol 1062 52650 1330679 2.2 MethodDictionary 2135 9854 1302376 2.1 MCVersionInfo 1313 22841 913640 1.5 Association 710 74216 890592 1.5 Character 6355 66219 794628 1.3 DateAndTime 7893 28026 672624 1.1 ByteArray 3458 640 639048 1.0
While my 1.1. deploy image (incl Seaside 3 and Glorp) has:
CompiledMethod 18784 53888 3082849 20.7 Bitmap 3753 184 2837256 19.0 ByteString 2515 47865 2713211 18.2 Array 2176 45399 2277268 15.3 ByteSymbol 1062 37522 925078 6.2 Character 6355 66219 794628 5.3 MethodDictionary 2135 6296 468456 3.1 WeakArray 718 127 324104 2.2 Association 710 23189 278268 1.9 ByteArray 3370 341 213357 1.4 ClassOrganizer 1326 6112 195584 1.3 Metaclass 3909 3078 123120 0.8
This reduction is done by ScriptLoader>>#cleanUpForRelease (after deleting all unit test packages).
Thanks Sven. It seems my mail was not clear at all. I know that with #cleanUpForRelease it will reduce, but my question is....if I understand correlty what a Bitmap is, why they are nstantiated when I am running headless? shouldn't the amount of instances be 0? I think I don't understand what really the -headless does. I thought the world was not display, not Bitmap was instanciated, etc... cheers Mariano
HTH,
Sven
On 24 Aug 2010, at 14:18, Mariano Martinez Peck wrote:
I took a dev image, and run them in two ways: the normal and headless. For each I did a:
"Smalltalk garbageCollect. SpaceTally new printSpaceAnalysis"
Normal one:
Class code space # instances inst space percent Bitmap 3753 133 11099904 37.4 ByteString 2515 85110 6106378 20.6 CompiledMethod 19130 59452 3703463 12.5 Array 2176 77579 2561928 8.6 ......
Headless:
Class code space # instances inst space percent ByteString 2515 85110 6106378 24.7 Bitmap 3753 126 6049208 24.5 CompiledMethod 19130 59452 3703463 15.0 Array 2176 77577 2561844 10.4 ......
So....even in headless mode, I have 133 instances of Bitmap, representing 24.5% of the memory.... Ok, 24.5 is better than 37.5, but I don't understand why Bitmap instances are created. Why they are needed ? is there a way to garbageCollect them?
thanks
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, On 24 Aug 2010, at 14:44, Mariano Martinez Peck wrote:
Thanks Sven. It seems my mail was not clear at all. I know that with #cleanUpForRelease it will reduce, but my question is....if I understand correlty what a Bitmap is, why they are nstantiated when I am running headless? shouldn't the amount of instances be 0?
I think I don't understand what really the -headless does. I thought the world was not display, not Bitmap was instanciated, etc...
OK, that is a different question, sorry. Isn't it so that these Bitmap instances are just regular Smalltalk objects that live the Smalltalk heap and that by definition all live Smalltalk objects get saved into the image file ? I don't think they are different from regular arrays. Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand. Sven
That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now. BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but... Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven@beta9.be] Sent: Tuesday, August 24, 2010 8:59 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode? Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand. Sven _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
It depends on how you look at it: a properly configured deployed seaside image will have zero windows and will never popup anything, so it makes no difference. I never use the RFB model, mostly out of principle, a server app should not have a classic gui. The seaside development tools allow you to upgrade MC packages, browse code, execute doits, save the image, kill processes, ... That being said, the headless support in VW 7 is very nice (mainly capturing display activity into errors, errors/transcript go to stdout/stderr/logfile, options to make std image headless and vice versa). Sven On 25 Aug 2010, at 12:18, Schwab,Wilhelm K wrote:
That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now.
BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but...
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven@beta9.be] Sent: Tuesday, August 24, 2010 8:59 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode?
Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand.
Sven
_______________________________________________ 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 25, 2010, at 12:49 PM, Sven Van Caekenberghe wrote:
It depends on how you look at it: a properly configured deployed seaside image will have zero windows and will never popup anything, so it makes no difference. I never use the RFB model, mostly out of principle, a server app should not have a classic gui. The seaside development tools allow you to upgrade MC packages, browse code, execute doits, save the image, kill processes, ...
That being said, the headless support in VW 7 is very nice (mainly capturing display activity into errors, errors/transcript go to stdout/stderr/logfile, options to make std image headless and vice versa).
we should arrive one day to that :)
Sven
On 25 Aug 2010, at 12:18, Schwab,Wilhelm K wrote:
That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now.
BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but...
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven@beta9.be] Sent: Tuesday, August 24, 2010 8:59 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode?
Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand.
Sven
_______________________________________________ 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
Options are always good. I would not at all recommend removing the current null display and sound drivers. However, it would be nice to see the image and vm cooperate to emulate Dolphin's session managers and associated deployment design. IMHO Object Arts went a little overboard with stripping; we would not have to work that hard at it to have something very useful. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, August 25, 2010 1:06 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [SPAM] Re: why are Bitmaps instanciated even in headless mode? On Aug 25, 2010, at 12:49 PM, Sven Van Caekenberghe wrote:
It depends on how you look at it: a properly configured deployed seaside image will have zero windows and will never popup anything, so it makes no difference. I never use the RFB model, mostly out of principle, a server app should not have a classic gui. The seaside development tools allow you to upgrade MC packages, browse code, execute doits, save the image, kill processes, ...
That being said, the headless support in VW 7 is very nice (mainly capturing display activity into errors, errors/transcript go to stdout/stderr/logfile, options to make std image headless and vice versa).
we should arrive one day to that :)
Sven
On 25 Aug 2010, at 12:18, Schwab,Wilhelm K wrote:
That makes complete sense, and it is a crushingly disappointing realization :( I'll get over it, but it is all the more reason to eventually strive for the Dolphin session-based model. Then deployed console apps would not have a GUI at all, for real. I will admit that there is something to be said for having something running headless and then magically popping into a GUI, locally or remotely, but something that is really headless, not merely making a bunch of calls that are artificially no-ops, has value too and we can't build that right now.
BTW, hopefully no one is thinking of making it impossible to create bitmaps when headless, right? That would be bad for web servers and other things that create graphics for use elsewhere. Sorry to even mention it, but...
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven@beta9.be] Sent: Tuesday, August 24, 2010 8:59 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why are Bitmaps instanciated even in headless mode?
Running -headless (actually -vm-display-null -vm-sound-null) just instructs the VM to connect to a dummy (null) display and sound device, so that display operations have no effect, as far as I understand.
Sven
_______________________________________________ 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
2010/8/24 Mariano Martinez Peck <marianopeck@gmail.com>:
2010/8/24 Sven Van Caekenberghe <sven@beta9.be>
Well, my 1.1 dev image has: Class              code space # instances  inst space percent Bitmap                 3753     8906    19427212  31.9 ByteString               2515    190202    17459895  28.6 Array                 2176    137567    5198744 8.5 CompiledMethod            19130    79223    4888481 8.0 ByteSymbol               1062    52650    1330679 2.2 MethodDictionary            2135     9854    1302376 2.1 MCVersionInfo             1313    22841     913640 1.5 Association               710    74216     890592 1.5 Character               6355    66219     794628 1.3 DateAndTime              7893    28026     672624 1.1 ByteArray               3458     640     639048 1.0 While my 1.1. deploy image (incl Seaside 3 and Glorp) has: CompiledMethod            18784    53888    3082849  20.7 Bitmap                 3753     184    2837256  19.0 ByteString               2515    47865    2713211  18.2 Array                 2176    45399    2277268  15.3 ByteSymbol               1062    37522     925078 6.2 Character               6355    66219     794628 5.3 MethodDictionary            2135     6296     468456 3.1 WeakArray                718     127     324104 2.2 Association               710    23189     278268 1.9 ByteArray               3370     341     213357 1.4 ClassOrganizer             1326     6112     195584 1.3 Metaclass               3909     3078     123120 0.8
This reduction is done by ScriptLoader>>#cleanUpForRelease (after deleting all unit test packages).
Thanks Sven. It seems my mail was not clear at all. I know that with #cleanUpForRelease it will reduce, but my question is....if I understand correlty what a Bitmap is, why they are nstantiated when I am running headless? shouldn't the amount of instances be 0?
I think I don't understand what really the -headless does. I thought the world was not display, not Bitmap was instanciated, etc...
Sure, you can still draw on the display, bitblit things, create morphs, move windows around, query pixels, etc. Display is a global variable that doesn't just disappear. Otherwise things like RFB Server and the Seaside Screen wouldn't work. Lukas -- Lukas Renggli www.lukas-renggli.ch
participants (5)
-
Lukas Renggli -
Mariano Martinez Peck -
Schwab,Wilhelm K -
Stéphane Ducasse -
Sven Van Caekenberghe