Hi Yoshiki,

On Tue, Jan 3, 2012 at 9:39 PM, Yoshiki Ohshima <yoshiki at vpri.org> wrote:

> At Tue, 3 Jan 2012 17:35:09 -0800,
> Eliot Miranda wrote:
> >
> > Hi Yoshiki,
> >
> > On Tue, Jan 3, 2012 at 4:29 PM, Yoshiki Ohshima <yoshiki at vpri.org>
> wrote:
> >
> >      Hello,
> >
> >      On the latest Cog VM and my image (not so latest), I don't seem to
> >     be able to get and set some vm parameters.  Specifically, the ones
> >     marked as "read-write" in the method comment give me "nil" when
> >     queried, and some strange value when try to set.  Is this a known
> >     issue?  And/or, Is there an image side change I should have?
> >
> > 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
> > 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:
> > [:i| Smalltalk getSystemAttribute: i]?
>
> Thank you, Eliot.
>
> The result from above do it is:
>
>  #('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
> http://www.squeakvm.org/svn/squeak/branches/Cog')
>
> But also happen with:
>  #('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)
>
> And I was wrong about "the ones marked as 'read-write'".  The result
> from (1 to: 40) select: [:i| (Smalltalk vmParameterAt: i) isNil] is
> #(4 5 34).
>
> The one I was originally interested in is 5, which the comment says
> "allocations between GCs (read-write)".  In my animation framework I
> see hiccups and trying to mitigate it.
>
> But now I increased the parameter 6 ("survivor count tenuring
> threshold (read-write)"), I see no hiccups.  Ok, so vm parameter 5 not
> working is not critical, but I'd still want to fiddle the number to
> experiment (if it is still relevant).
>

Ah, ok.  Parameters 4 & 5 do not apply to the Stack and Cog VMs.  They are

4 nil (was allocationCount (read-only))
5 nil (was allocations between GCs (read-write)

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.
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120104/74629542/attachment.htm