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

Tue May 18 19:17:04 UTC 2010

On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse <
stephane.ducasse at inria.fr> 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 <siguctua at gmail.com>
> wrote:
> > 2010/5/17 Eliot Miranda <eliot.miranda at gmail.com>:
> > >
> > >
> > > On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse
> > > <stephane.ducasse at inria.fr> 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
> > >> Pharo-project at lists.gforge.inria.fr
> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> > >
> > >
> > > _______________________________________________
> > > Pharo-project mailing list
> > > Pharo-project at lists.gforge.inria.fr
> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> > >
> >
> >
> >
> > --
> > Best regards,
> > Igor Stasenko AKA sig.
> >
> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-project at lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
> > _______________________________________________
> > Pharo-project mailing list
> > Pharo-project at lists.gforge.inria.fr
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100518/7fc27d7f/attachment-0001.htm