On Feb 28, 2008, at 1:31 PM, Andreas Raab wrote:

"These settings describe what to do when we're close to running out of free space"

"Tell the VM that we'd rather grow than spinning in tight GC loops" Smalltalk gcBiasToGrow: true. "default: false" "Tell the VM to do a fullGC for good measure if the above growth exceeded 16MB" Smalltalk gcBiasToGrowLimit: 16*1024*1024. "default: 0"

Cheers,

• Andreas

Further to this in Sophie we have a SophieMemoryPolicy which does passive checking for certain things and perhaps changes things on the fly

The real issue is when the root table points to many arrays and we have to scan each Array looking for the young object, that leads to excessive work in the IGC.

But I know that cases arises when we see (statMarkCount ) > (statAllocationCount*2) so we force a tenure which fixes the problem.

I experimented with setting goals for the new space object allocation, and tenuring threshold. This works ok if you have a particular ms wait for a IGC in mind and perhaps a server type of load, if you have a server test suite that mimics your workload then fiddling with Smalltalk vmParameterAt: 5/6 on the fly might alter things (good/bad).

calculateGoals | target |

vmNotSupported = true ifTrue: [^self].

(statMarkCount ) > (statAllocationCount*2) ifTrue: [[Smalltalk forceTenure] on: Error do: [:ex | ]]. "Tenure if we think too much root table marking is going on"

true ifTrue: [^self].

" Logic below is not used, still there in case one wants to try it " "Unused logic to set allocation and tenure limits to reach some sort of icremental GC ms time"

(statIGCDeltaTime = 0) ifTrue: [target _ (Smalltalk vmParameterAt: 5)+21. Smalltalk vmParameterAt: 5 put: target. "do an incremental GC after this many allocations" Smalltalk vmParameterAt: 6 put: target*3//4. "tenure when more than this many objects survive the GC"]. (statIGCDeltaTime > 0) ifTrue: [target _ ((Smalltalk vmParameterAt: 5)-27) max: 2000. Smalltalk vmParameterAt: 5 put: target. "do an incremental GC after this many allocations" Smalltalk vmParameterAt: 6 put: target*3//4. "tenure when more than this many objects survive the GC"].

(statIGCDeltaTime < 1) ifTrue: [target _ (Smalltalk vmParameterAt: 5)+21. Smalltalk vmParameterAt: 5 put: target. "do an incremental GC after this many allocations" Smalltalk vmParameterAt: 6 put: target*3//4. "tenure when more than this many objects survive the GC"]. (statIGCDeltaTime > 1) ifTrue: [target _ ((Smalltalk vmParameterAt: 5)-27) max: 4000. Smalltalk vmParameterAt: 5 put: target. "do an incremental GC after this many allocations" Smalltalk vmParameterAt: 6 put: target*3//4. "tenure when more than this many objects survive the GC"].

-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

That I wrote. In all the macintosh carbon VM for a few years now.

On Feb 28, 2008, at 7:59 PM, Jon Hylands wrote:

On Thu, 28 Feb 2008 13:31:15 -0800, Andreas Raab andreas.raab@gmx.de wrote:

...

"Tell the VM that we'd rather grow than spinning in tight GC loops" Smalltalk gcBiasToGrow: true. "default: false" "Tell the VM to do a fullGC for good measure if the above growth exceeded 16MB" Smalltalk gcBiasToGrowLimit: 16*1024*1024. "default: 0"

Andreas,

I can't find any Squeak images that implement #gcBiasToGrow:... Is that something you wrote, or part of some package I don't have?

Thanks, Jon

---

Jon Hylands Jon@huv.com http://www.huv.com/jon

Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog

-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Jon Hylands wrote:

I can't find any Squeak images that implement #gcBiasToGrow:... Is that something you wrote, or part of some package I don't have?

It's been part of the VM for a long time but not exposed to the image in any shape or form. We added it to Croquet:

SystemDictionary>>gcBiasToGrow: aBool "Tell the VM to grow after tenures instead of running in a tight loop where it does IGCs over and over. For some weird reason the primitive takes an integer not a bool but oh well..." self primitiveGCBiasToGrow: (aBool ifTrue:[1] ifFalse:[0])

SystemDictionary>>primitiveGCBiasToGrow: arg "Tell the VM to grow after tenures instead of running in a tight loop where it does IGCs over and over. For some weird reason the primitive takes an integer not a bool but oh well..." <primitive: 'primitiveSetGCBiasToGrow'> ^self primitiveFailed

Ditto for any others that may be missing.

Cheers, - Andreas

Klaus D. Witzel wrote:

I suggest to activate the #initializeMemorySettings which Andreas posted in the squeak-dev and -web .images. TIA.

I wouldn't. These settings were chosen to balance the tradeoffs between interactive rates (real-time voice and sound processing) as well as large memory allocations (big chunks of memory for textures etc). For a web-image (which has no real-time constraints) I would almost certainly choose different values. And for an image that usually stays below 100MB in size, I would choose even different values.

For example, for the web image try: - allocation between GCs: 100,000 - tenuring threshold: 25,000 (maybe even 35,000) The above will GC less often but take slightly longer (20ms maybe depending on your speed). But it will tenure much less often and consequently grow more slowly. This can often compensate for working sets that are accessed over longer periods of time (I would expect Seaside to show such behavior).

Cheers, - Andreas

Hi Klaus and Andreas,

On Fri, Feb 29, 2008 at 8:04 AM, Klaus D. Witzel klaus.witzel@cobss.com wrote:

Damien,

I suggest to activate the #initializeMemorySettings which Andreas posted in the squeak-dev and -web .images. TIA.

I don't know what you are talking about :-). The best thing I can do is to let you modify http://squeaksource.com/ImageForDevelopers/ directly. Then, when you finishes, I will update the universe. Do you agree? If yes, you can start coding because the reposiroty is already open (and has always been).

I see squeak-web as an IDE to develop web applications, not as a web application server. So, I'm not sure if it requires different parameters than squeak-dev.

Bye

Hi,

On Fri, Feb 29, 2008 at 12:23 PM, Klaus D. Witzel klaus.witzel@cobss.com wrote:

On Fri, 29 Feb 2008 11:24:54 +0100, Damien Cassou wrote:

...

I don't know what you are talking about :-). The best thing I can do is to let you modify http://squeaksource.com/ImageForDevelopers/ directly. Then, when you finishes, I will update the universe. Do you agree?

Of course, since there seems to be no other choice :)

...

If yes, you can start coding because the reposiroty is already open (and has always been).

I see 2 commits now in squeaksource/ImageForDevelopers: kwl.147 kwl.148. Is that you Klaus? If I understand correctly, you want me to execute 'SmalltalkImage current initializeMemorySettingsProfileQF', right?

On Mon, Mar 3, 2008 at 9:41 AM, Klaus D. Witzel klaus.witzel@cobss.com wrote:

...

I see 2 commits now in squeaksource/ImageForDevelopers: kwl.147 kwl.148. Is that you Klaus?

Right. Unfortunately SqueakSource doesn't want to know who you are when posting is open to the world.

I think it does if you use your login/password to commit.

...

If I understand correctly, you want me to execute 'SmalltalkImage current initializeMemorySettingsProfileQF', right?

No; in a last minute decision I wrote the script's code+comment (see the commit's description), to be included in the Script Manager preferably as a new entry #initializeMemorySettings and mentioned in the welcome. It would also be worth to mention that people should use the latest and greatest VM which has fix

• http://bugs.squeak.org/view.php?id=6667

before wondering about what #gcBiasToGrow* does for them.

I haven't seen anything about writing to the script manager in the class DEVImage. If you want to write a documentation in the ScriptManager, just add a method in the method category 'build documentation'

...

...

out of curiosity (forgot the reason) in a Workspace I did a:= Array new: 100000000 withAll: 1.0

Unless I'm mistaken, this is two objects, an Array and a Float.

Add block contexts created for each iteration for filling array with value.

For #to:do: ? And anyway I'd hope they are short-lived and don't make it into oldspace.

What Klaus wanted was, more likely, something like

(1 to: n) collect: [ :each | each asFloat ]

(Don't try it at home with n = 100,000,000)

Paolo

On Fri, 29 Feb 2008 09:45:37 +0100, Paolo Bonzini wrote:

...

What Klaus wanted was, more likely, something like

Herbert, not Klaus. :-)

I can want that too, NP :)

Paolo

Hello Paolo,

PB> Unless I'm mistaken, this is two objects, an Array and a Float.

actually you seem to be right, Float allInstances size only gives some 28000 Floats after having created my big Array.

So I guess the other replies are valid (time is spent in GC) but for a different reason.

I'll tuck the informations away for the time I really have use for them.

Cheers

Herbert mailto:herbertkoenig@gmx.net