Hi Yoshiki,<br><br><div class="gmail_quote">On Tue, Jan 3, 2012 at 9:39 PM, Yoshiki Ohshima <span dir="ltr"><<a href="mailto:yoshiki@vpri.org">yoshiki@vpri.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
At Tue, 3 Jan 2012 17:35:09 -0800,<br>
<div><div></div><div class="h5">Eliot Miranda wrote:<br>
><br>
> Hi Yoshiki,<br>
><br>
> On Tue, Jan 3, 2012 at 4:29 PM, Yoshiki Ohshima <<a href="mailto:yoshiki@vpri.org">yoshiki@vpri.org</a>> wrote:<br>
><br>
> Hello,<br>
><br>
> On the latest Cog VM and my image (not so latest), I don't seem to<br>
> be able to get and set some vm parameters. Specifically, the ones<br>
> marked as "read-write" in the method comment give me "nil" when<br>
> queried, and some strange value when try to set. Is this a known<br>
> issue? And/or, Is there an image side change I should have?<br>
><br>
> Which indices exactly? The comment might be wrong. The Cog and Stack VMs have a modified garbage collector in which certain parameters no longer make sense and are answered as nil. I need<br>
> to know which indices to distinguish between intended behaviour and a bug (and the comment might merely be wrong). Also which VM exactly? i.e. what do you get for (1006 to: 1009) collect:<br>
> [:i| Smalltalk getSystemAttribute: i]?<br>
<br>
</div></div>Thank you, Eliot.<br>
<br>
The result from above do it is:<br>
<br>
#('Mac OS X built on Dec 13 2011 16:01:43 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3)' 'CoInterpreter VMMaker.oscog-eem.140 uuid: 2487009c-2c13-4609-b89e-77f0e195f433 Dec 13 2011' 'StackToRegisterMappingCogit VMMaker.oscog-eem.139 uuid: c2849383-9768-4948-b9b2-a5c22d482b07 Dec 13 2011' 'r2522 <a href="http://www.squeakvm.org/svn/squeak/branches/Cog" target="_blank">http://www.squeakvm.org/svn/squeak/branches/Cog</a>')<br>
<br>
But also happen with:<br>
#('Mac OS X built on Apr 26 2011 18:24:51 Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3)' 'CoInterpreter VMMaker.oscog-eem.56 uuid: fbf17bd2-ddbc-488f-b70d-3b9ba8906430 Apr 26 2011' 'StackToRegisterMappingCogit VMMaker-oscog.51 uuid: d213bf61-5898-475b-8a5c-e4a9bdad2415 Apr 26 2011' nil)<br>
<br>
And I was wrong about "the ones marked as 'read-write'". The result<br>
from (1 to: 40) select: [:i| (Smalltalk vmParameterAt: i) isNil] is<br>
#(4 5 34).<br>
<br>
The one I was originally interested in is 5, which the comment says<br>
"allocations between GCs (read-write)". In my animation framework I<br>
see hiccups and trying to mitigate it.<br>
<br>
But now I increased the parameter 6 ("survivor count tenuring<br>
threshold (read-write)"), I see no hiccups. Ok, so vm parameter 5 not<br>
working is not critical, but I'd still want to fiddle the number to<br>
experiment (if it is still relevant).<br></blockquote><div><br></div><div>Ah, ok. Parameters 4 & 5 do not apply to the Stack and Cog VMs. They are</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>4<span class="Apple-tab-span" style="white-space:pre"> </span>nil (was allocationCount (read-only))</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>5<span class="Apple-tab-span" style="white-space:pre"> </span>nil (was allocations between GCs (read-write)</div><div><br></div><div>and the method comment is wrong (I'll try and fix it soon). The reason is that the allocator in Stack/Cog (NewObjectMemory) triggers "incremental" collections (actually scavenges) once new space allocations have moved the allocation pointer past a tide mark, instead of using an allocation counter. This is for performance; a) the read-modify-write cycle of the allocation count is too expensive to contemplate :), and b) basing scavenging on how much memory has been allocated is better than using the object count since the size of objects allocated could cause the system not to scavenge soon enough to reclaim memory if large objects are allocated, and could cause too many scavenges if lots of small objects are allocated.</div>
</div>-- <br>best,<div>Eliot</div><br>