On May 18, 2010, at 7:21 PM, Eliot Miranda wrote:
>
>
> On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <
siguctua@gmail.com> wrote:
> 2010/5/17 Eliot Miranda <
eliot.miranda@gmail.com>:
> >
> >
> > On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse
> > <
stephane.ducasse@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@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.
>
> _______________________________________________
> 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