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