how to change the default size of the Pharo host windows?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: how to change the default size of the Pharo host windows?

Mariano Martinez Peck


On Tue, May 18, 2010 at 9:52 AM, Igor Stasenko <[hidden email]> wrote:
2010/5/18 Stéphane Ducasse <[hidden email]>:
> this is cool
> We could then build tools for you :)
> Boxes are packages, little squares are classes
>
>
> Blue: classes with no instances
> Green: classes with instances, but no used
> Red: classes with instances and at least one used
>
> just brainstorming with mariano
>
Interesting.
Could it draw with pink, the ones who has no instances, but having a
methods invocations
(an abstract superclasses can have no instances, but can be under heavy use).

Sorry I forgot to change the colors. Look above to see the references.

Cheers

Mariano


 

>
>
>
>
>
> On May 17, 2010, at 10:40 PM, Eliot Miranda wrote:
>
>>
>>
>> On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse <[hidden email]> wrote:
>>
>> On Ma
>> >
>> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also uses bits 1 through 4
>> >               bit 0: 1 => open full screen, 0 => open using width & height
>> >               bit 1: 1 => image floats are in little-endian format, 0=> image floats are in big-endian format
>> >               bit 2: 1 => Process's 4th inst var (after myList) is threadId to be used by the VM for overlapped calls
>> >
>> >               bit 3: 1 => set the flag bit on methods that the VM will only interpret (because they're considered too big to JIT)
>> >               bit 4: 1 => preempting a process does not put it to the back of its run queue
>>
>>
>> I was not clear how to read
>>        bit 3: 1
>> this information is not in the compiledMethods?
>>
>> For the Cog JIT I want to measure which methods get interpreted to determine the threshold at which to decide to JIT methods.  It makes little sense to JIT methods that are large and only executed once, typically class initialization methods. A simple criterion is to set a limit on the number of literals in a method.  But I still need to know whether my threshold is affecting frequently used methods.  So I added the option of setting the flag bit in any method which the JIT refuses to compile because it has too many literals.  Since I need to see which methods are interpreted on start-up putting a flag in the image header was convenient.  The effect is that the JIT will set the flag bit on any method it refuses to JIT.  I can then browse these in the image and decide whether any are important and adjust the threshold accordingly.  Arguably this should be a command line argument, not an image header flag.
>>
>>
>> Stef
>>
>>
>> _______________________________________________
>> 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

withAbstractClasses.jpeg (485K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: how to change the default size of the Pharo host windows?

Eliot Miranda-2
In reply to this post by Igor Stasenko


On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <[hidden email]> wrote:
2010/5/17 Eliot Miranda <[hidden email]>:
>
>
> On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse
> <[hidden email]> wrote:
>>
>> On Ma
>> >
>> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also
>> > uses bits 1 through 4
>> >               bit 0: 1 => open full screen, 0 => open using width &
>> > height
>> >               bit 1: 1 => image floats are in little-endian format, 0=>
>> > image floats are in big-endian format
>> >               bit 2: 1 => Process's 4th inst var (after myList) is
>> > threadId to be used by the VM for overlapped calls
>> >
>> >               bit 3: 1 => set the flag bit on methods that the VM will
>> > only interpret (because they're considered too big to JIT)
>> >               bit 4: 1 => preempting a process does not put it to the
>> > back of its run queue
>>
>>
>> I was not clear how to read
>>        bit 3: 1
>> this information is not in the compiledMethods?
>
> For the Cog JIT I want to measure which methods get interpreted to determine
> the threshold at which to decide to JIT methods.  It makes little sense to
> JIT methods that are large and only executed once, typically class
> initialization methods. A simple criterion is to set a limit on the number
> of literals in a method.  But I still need to know whether my threshold is
> affecting frequently used methods.  So I added the option of setting the
> flag bit in any method which the JIT refuses to compile because it has too
> many literals.  Since I need to see which methods are interpreted on
> start-up putting a flag in the image header was convenient.  The effect is
> that the JIT will set the flag bit on any method it refuses to JIT.  I can
> then browse these in the image and decide whether any are important and
> adjust the threshold accordingly.  Arguably this should be a command line
> argument, not an image header flag.

Eliot, i beg you, instead of using an obscure flags in image header,
just add (or reserve unused) splObject indice and read/write whatever
you want from there.

SOme times it isn't appropriate to put flags in the special objects array.  Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray.  For all the flags which can be set in the header I provide access through vmParameterAt:[put:].


I guess that Cog having substantial changes all around places, so
adding a convenient API for VM flags
and removing a bit fiddling from image header, would make things
transparent and easy to use from language side.

Ah, ok.  That exists in vmParameterAt:[put:].  i.e. here's what's different in vmParameterAt:put: at Teleplace:
VM parameters are numbered as follows:
...
4 allocationCount (read-only; nil in Cog VMs)
5 allocations between GCs (read-write; nil in Cog VMs)
...
41 imageFormatVersion for the VM
42 number of stack pages in use (Cog Stack VM only, otherwise nil)
43 desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil)
44 size of eden, in bytes (Cog VMs only, otherwise nil)
45 desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil)
46 size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil)
47 desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only)
48 various properties of the Cog VM as an integer encoding an array of bit flags.
Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative)
 Bit 1: if set, methods that are interpreted will have the flag bit set in their header
 Bit 2: if set, implies preempting a process does not put it to the back of its run queue
49-55 reserved for VM parameters that persist in the image (such as eden above)
56 number of process switches since startup (read-only)
57 number of ioProcessEvents calls since startup (read-only)
58 number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only)
59 number of check event calls since startup (read-only)
60 number of stack page overflows since startup (read-only; Cog VMs only)
61 number of stack page divorces since startup (read-only; Cog VMs only)
62 compiled code compactions since startup (read-only; Cog only; otherwise nil)
63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)





>>
>> Stef
>>
>>
>> _______________________________________________
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: how to change the default size of the Pharo host windows?

Stéphane Ducasse
cool we could turn them into nice query methods with semantics revealing names :)

On May 18, 2010, at 7:21 PM, Eliot Miranda wrote:

>
>
> On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <[hidden email]> wrote:
> 2010/5/17 Eliot Miranda <[hidden email]>:
> >
> >
> > On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse
> > <[hidden email]> wrote:
> >>
> >> On Ma
> >> >
> >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also
> >> > uses bits 1 through 4
> >> >               bit 0: 1 => open full screen, 0 => open using width &
> >> > height
> >> >               bit 1: 1 => image floats are in little-endian format, 0=>
> >> > image floats are in big-endian format
> >> >               bit 2: 1 => Process's 4th inst var (after myList) is
> >> > threadId to be used by the VM for overlapped calls
> >> >
> >> >               bit 3: 1 => set the flag bit on methods that the VM will
> >> > only interpret (because they're considered too big to JIT)
> >> >               bit 4: 1 => preempting a process does not put it to the
> >> > back of its run queue
> >>
> >>
> >> I was not clear how to read
> >>        bit 3: 1
> >> this information is not in the compiledMethods?
> >
> > For the Cog JIT I want to measure which methods get interpreted to determine
> > the threshold at which to decide to JIT methods.  It makes little sense to
> > JIT methods that are large and only executed once, typically class
> > initialization methods. A simple criterion is to set a limit on the number
> > of literals in a method.  But I still need to know whether my threshold is
> > affecting frequently used methods.  So I added the option of setting the
> > flag bit in any method which the JIT refuses to compile because it has too
> > many literals.  Since I need to see which methods are interpreted on
> > start-up putting a flag in the image header was convenient.  The effect is
> > that the JIT will set the flag bit on any method it refuses to JIT.  I can
> > then browse these in the image and decide whether any are important and
> > adjust the threshold accordingly.  Arguably this should be a command line
> > argument, not an image header flag.
>
> Eliot, i beg you, instead of using an obscure flags in image header,
> just add (or reserve unused) splObject indice and read/write whatever
> you want from there.
>
> SOme times it isn't appropriate to put flags in the special objects array.  Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray.  For all the flags which can be set in the header I provide access through vmParameterAt:[put:].
>
>
> I guess that Cog having substantial changes all around places, so
> adding a convenient API for VM flags
> and removing a bit fiddling from image header, would make things
> transparent and easy to use from language side.
>
> Ah, ok.  That exists in vmParameterAt:[put:].  i.e. here's what's different in vmParameterAt:put: at Teleplace:
> VM parameters are numbered as follows:
> ...
> 4 allocationCount (read-only; nil in Cog VMs)
> 5 allocations between GCs (read-write; nil in Cog VMs)
> ...
> 41 imageFormatVersion for the VM
> 42 number of stack pages in use (Cog Stack VM only, otherwise nil)
> 43 desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil)
> 44 size of eden, in bytes (Cog VMs only, otherwise nil)
> 45 desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil)
> 46 size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil)
> 47 desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only)
> 48 various properties of the Cog VM as an integer encoding an array of bit flags.
> Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative)
> Bit 1: if set, methods that are interpreted will have the flag bit set in their header
> Bit 2: if set, implies preempting a process does not put it to the back of its run queue
> 49-55 reserved for VM parameters that persist in the image (such as eden above)
> 56 number of process switches since startup (read-only)
> 57 number of ioProcessEvents calls since startup (read-only)
> 58 number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only)
> 59 number of check event calls since startup (read-only)
> 60 number of stack page overflows since startup (read-only; Cog VMs only)
> 61 number of stack page divorces since startup (read-only; Cog VMs only)
> 62 compiled code compactions since startup (read-only; Cog only; otherwise nil)
> 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)
>
>
>
>
>
> >>
> >> Stef
> >>
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: how to change the default size of the Pharo host windows?

Eliot Miranda-2


On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse <[hidden email]> wrote:
cool we could turn them into nice query methods with semantics revealing names :)

I would just use a SHaredPool with class variables appropriately named, e.g.

SharedPool subclass: #VMParameterNames
instanceVariableNames: ''
classVariableNames: '... ImageFormatVersion ...'

VMParameterNames class methods for initialization
initialize
...
ImageFormatVersion := 41
...

then a client would use things like

Smalltalk image vmParameterAt: ImageFormatVersion

These are for very special uses and I don't really like the idea of making access to them too easy.



On May 18, 2010, at 7:21 PM, Eliot Miranda wrote:

>
>
> On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <[hidden email]> wrote:
> 2010/5/17 Eliot Miranda <[hidden email]>:
> >
> >
> > On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse
> > <[hidden email]> wrote:
> >>
> >> On Ma
> >> >
> >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also
> >> > uses bits 1 through 4
> >> >               bit 0: 1 => open full screen, 0 => open using width &
> >> > height
> >> >               bit 1: 1 => image floats are in little-endian format, 0=>
> >> > image floats are in big-endian format
> >> >               bit 2: 1 => Process's 4th inst var (after myList) is
> >> > threadId to be used by the VM for overlapped calls
> >> >
> >> >               bit 3: 1 => set the flag bit on methods that the VM will
> >> > only interpret (because they're considered too big to JIT)
> >> >               bit 4: 1 => preempting a process does not put it to the
> >> > back of its run queue
> >>
> >>
> >> I was not clear how to read
> >>        bit 3: 1
> >> this information is not in the compiledMethods?
> >
> > For the Cog JIT I want to measure which methods get interpreted to determine
> > the threshold at which to decide to JIT methods.  It makes little sense to
> > JIT methods that are large and only executed once, typically class
> > initialization methods. A simple criterion is to set a limit on the number
> > of literals in a method.  But I still need to know whether my threshold is
> > affecting frequently used methods.  So I added the option of setting the
> > flag bit in any method which the JIT refuses to compile because it has too
> > many literals.  Since I need to see which methods are interpreted on
> > start-up putting a flag in the image header was convenient.  The effect is
> > that the JIT will set the flag bit on any method it refuses to JIT.  I can
> > then browse these in the image and decide whether any are important and
> > adjust the threshold accordingly.  Arguably this should be a command line
> > argument, not an image header flag.
>
> Eliot, i beg you, instead of using an obscure flags in image header,
> just add (or reserve unused) splObject indice and read/write whatever
> you want from there.
>
> SOme times it isn't appropriate to put flags in the special objects array.  Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray.  For all the flags which can be set in the header I provide access through vmParameterAt:[put:].
>
>
> I guess that Cog having substantial changes all around places, so
> adding a convenient API for VM flags
> and removing a bit fiddling from image header, would make things
> transparent and easy to use from language side.
>
> Ah, ok.  That exists in vmParameterAt:[put:].  i.e. here's what's different in vmParameterAt:put: at Teleplace:
>       VM parameters are numbered as follows:
>               ...
>               4       allocationCount (read-only; nil in Cog VMs)
>               5       allocations between GCs (read-write; nil in Cog VMs)
>               ...
>               41      imageFormatVersion for the VM
>               42      number of stack pages in use (Cog Stack VM only, otherwise nil)
>               43      desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil)
>               44      size of eden, in bytes (Cog VMs only, otherwise nil)
>               45      desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil)
>               46      size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil)
>               47      desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only)
>               48      various properties of the Cog VM as an integer encoding an array of bit flags.
>                        Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative)
>                        Bit 1: if set, methods that are interpreted will have the flag bit set in their header
>                        Bit 2: if set, implies preempting a process does not put it to the back of its run queue
>               49-55 reserved for VM parameters that persist in the image (such as eden above)
>               56      number of process switches since startup (read-only)
>               57      number of ioProcessEvents calls since startup (read-only)
>               58      number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only)
>               59      number of check event calls since startup (read-only)
>               60      number of stack page overflows since startup (read-only; Cog VMs only)
>               61      number of stack page divorces since startup (read-only; Cog VMs only)
>               62      compiled code compactions since startup (read-only; Cog only; otherwise nil)
>               63      total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)
>
>
>
>
>
> >>
> >> Stef
> >>
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Vm-dev] Re: how to change the default size of the Pharo host windows?

Igor Stasenko
On 18 May 2010 22:17, Eliot Miranda <[hidden email]> wrote:

>
>
>
> On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse <[hidden email]> wrote:
>>
>> cool we could turn them into nice query methods with semantics revealing names :)
>
> I would just use a SHaredPool with class variables appropriately named, e.g.
> SharedPool subclass: #VMParameterNames
> instanceVariableNames: ''
> classVariableNames: '... ImageFormatVersion ...'
> VMParameterNames class methods for initialization
> initialize
> ...
> ImageFormatVersion := 41
> ...
> then a client would use things like
> Smalltalk image vmParameterAt: ImageFormatVersion
> These are for very special uses and I don't really like the idea of making access to them too easy.
>

With such excuse, were ending up with a hacky shell scripts - an
ultimately afwul way to access
these attributes. It should be easier :)

Its been always easy to make a mess:
Array setFormat: 88888.
Array new.
bye-bye vm & image.

Just give developers freedom, and then it is their own responsibility
to not make mess out of it, not yours.

--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12