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 willonly 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
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda