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

Eliot Miranda eliot.miranda at gmail.com
Tue May 18 17:21:23 UTC 2010


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100518/b9c87125/attachment.htm


More information about the Vm-dev mailing list