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 <siguc...@gmail.com> wrote: > 2010/5/17 Eliot Miranda <eliot.mira...@gmail.com>: > > > > > > On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse > > <stephane.duca...@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
