<br><br><div class="gmail_quote">On Tue, May 18, 2010 at 11:52 AM, Stéphane Ducasse <span dir="ltr">&lt;<a href="mailto:stephane.ducasse@inria.fr">stephane.ducasse@inria.fr</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
cool we could turn them into nice query methods with semantics revealing names :)<br></blockquote><div><br></div><div>I would just use a SHaredPool with class variables appropriately named, e.g.</div><div><br></div><div>SharedPool subclass: #VMParameterNames</div>
<div><span class="Apple-tab-span" style="white-space:pre">        </span>instanceVariableNames: &#39;&#39;</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>classVariableNames: &#39;... ImageFormatVersion ...&#39;</div>
<div><br></div><div>VMParameterNames class methods for initialization</div><div>initialize</div><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>...</div><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>ImageFormatVersion := 41</div>
<span class="Apple-tab-span" style="white-space: pre; ">        </span>...</div><div class="gmail_quote"><br><div>then a client would use things like</div><div><br></div><div><span class="Apple-tab-span" style="white-space: pre; ">        </span>Smalltalk image vmParameterAt: ImageFormatVersion</div>
<div><br></div><div>These are for very special uses and I don&#39;t really like the idea of making access to them too easy.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5"><br>
On May 18, 2010, at 7:21 PM, Eliot Miranda wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt; On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko &lt;<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>&gt; wrote:<br>
&gt; 2010/5/17 Eliot Miranda &lt;<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>&gt;:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Mon, May 17, 2010 at 11:30 AM, Stéphane Ducasse<br>
&gt; &gt; &lt;<a href="mailto:stephane.ducasse@inria.fr">stephane.ducasse@inria.fr</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On Ma<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt; bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also<br>
&gt; &gt;&gt; &gt; uses bits 1 through 4<br>
&gt; &gt;&gt; &gt;               bit 0: 1 =&gt; open full screen, 0 =&gt; open using width &amp;<br>
&gt; &gt;&gt; &gt; height<br>
&gt; &gt;&gt; &gt;               bit 1: 1 =&gt; image floats are in little-endian format, 0=&gt;<br>
&gt; &gt;&gt; &gt; image floats are in big-endian format<br>
&gt; &gt;&gt; &gt;               bit 2: 1 =&gt; Process&#39;s 4th inst var (after myList) is<br>
&gt; &gt;&gt; &gt; threadId to be used by the VM for overlapped calls<br>
&gt; &gt;&gt; &gt;<br>
&gt; &gt;&gt; &gt;               bit 3: 1 =&gt; set the flag bit on methods that the VM will<br>
&gt; &gt;&gt; &gt; only interpret (because they&#39;re considered too big to JIT)<br>
&gt; &gt;&gt; &gt;               bit 4: 1 =&gt; preempting a process does not put it to the<br>
&gt; &gt;&gt; &gt; back of its run queue<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I was not clear how to read<br>
&gt; &gt;&gt;        bit 3: 1<br>
&gt; &gt;&gt; this information is not in the compiledMethods?<br>
&gt; &gt;<br>
&gt; &gt; For the Cog JIT I want to measure which methods get interpreted to determine<br>
&gt; &gt; the threshold at which to decide to JIT methods.  It makes little sense to<br>
&gt; &gt; JIT methods that are large and only executed once, typically class<br>
&gt; &gt; initialization methods. A simple criterion is to set a limit on the number<br>
&gt; &gt; of literals in a method.  But I still need to know whether my threshold is<br>
&gt; &gt; affecting frequently used methods.  So I added the option of setting the<br>
&gt; &gt; flag bit in any method which the JIT refuses to compile because it has too<br>
&gt; &gt; many literals.  Since I need to see which methods are interpreted on<br>
&gt; &gt; start-up putting a flag in the image header was convenient.  The effect is<br>
&gt; &gt; that the JIT will set the flag bit on any method it refuses to JIT.  I can<br>
&gt; &gt; then browse these in the image and decide whether any are important and<br>
&gt; &gt; adjust the threshold accordingly.  Arguably this should be a command line<br>
&gt; &gt; argument, not an image header flag.<br>
&gt;<br>
&gt; Eliot, i beg you, instead of using an obscure flags in image header,<br>
&gt; just add (or reserve unused) splObject indice and read/write whatever<br>
&gt; you want from there.<br>
&gt;<br>
&gt; SOme times it isn&#39;t appropriate to put flags in the special objects array.  Further, changing the specialObjectsArray isn&#39;t only a VM change, its also a change to SystemDictionary&gt;&gt;recreateSpecialObjectsArray.  For all the flags which can be set in the header I provide access through vmParameterAt:[put:].<br>

&gt;<br>
&gt;<br>
&gt; I guess that Cog having substantial changes all around places, so<br>
&gt; adding a convenient API for VM flags<br>
&gt; and removing a bit fiddling from image header, would make things<br>
&gt; transparent and easy to use from language side.<br>
&gt;<br>
&gt; Ah, ok.  That exists in vmParameterAt:[put:].  i.e. here&#39;s what&#39;s different in vmParameterAt:put: at Teleplace:<br>
&gt;       VM parameters are numbered as follows:<br>
&gt;               ...<br>
&gt;               4       allocationCount (read-only; nil in Cog VMs)<br>
&gt;               5       allocations between GCs (read-write; nil in Cog VMs)<br>
&gt;               ...<br>
&gt;               41      imageFormatVersion for the VM<br>
&gt;               42      number of stack pages in use (Cog Stack VM only, otherwise nil)<br>
&gt;               43      desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil)<br>
&gt;               44      size of eden, in bytes (Cog VMs only, otherwise nil)<br>
&gt;               45      desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil)<br>
&gt;               46      size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil)<br>
&gt;               47      desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only)<br>
&gt;               48      various properties of the Cog VM as an integer encoding an array of bit flags.<br>
&gt;                        Bit 0: implies the image&#39;s Process class has threadId as its 3rd inst var (zero relative)<br>
&gt;                        Bit 1: if set, methods that are interpreted will have the flag bit set in their header<br>
&gt;                        Bit 2: if set, implies preempting a process does not put it to the back of its run queue<br>
&gt;               49-55 reserved for VM parameters that persist in the image (such as eden above)<br>
&gt;               56      number of process switches since startup (read-only)<br>
&gt;               57      number of ioProcessEvents calls since startup (read-only)<br>
&gt;               58      number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only)<br>
&gt;               59      number of check event calls since startup (read-only)<br>
&gt;               60      number of stack page overflows since startup (read-only; Cog VMs only)<br>
&gt;               61      number of stack page divorces since startup (read-only; Cog VMs only)<br>
&gt;               62      compiled code compactions since startup (read-only; Cog only; otherwise nil)<br>
&gt;               63      total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Stef<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; _______________________________________________<br>
&gt; &gt;&gt; Pharo-project mailing list<br>
&gt; &gt;&gt; <a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>
&gt; &gt;&gt; <a href="http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project" target="_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project</a><br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Pharo-project mailing list<br>
&gt; &gt; <a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>
&gt; &gt; <a href="http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project" target="_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project</a><br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Best regards,<br>
&gt; Igor Stasenko AKA sig.<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Pharo-project mailing list<br>
&gt; <a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>
&gt; <a href="http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project" target="_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Pharo-project mailing list<br>
&gt; <a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>
&gt; <a href="http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project" target="_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project</a><br>
<br>
<br>
_______________________________________________<br>
Pharo-project mailing list<br>
<a href="mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@lists.gforge.inria.fr</a><br>
<a href="http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project" target="_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project</a><br>
</div></div></blockquote></div><br>