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? Thank you! -- Yoshiki |
Hi Yoshiki,
On Tue, Jan 3, 2012 at 4:29 PM, Yoshiki Ohshima <[hidden email]> wrote: Hello, 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]?
best, Eliot |
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 <[hidden email]> 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). -- Yoshiki |
Hi Yoshiki,
On Tue, Jan 3, 2012 at 9:39 PM, Yoshiki Ohshima <[hidden email]> wrote: -- At Tue, 3 Jan 2012 17:35:09 -0800, 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 |
Free forum by Nabble | Edit this page |