[Seaside] seaside performance in Squeak

[John M McIntosh]

If your C code in interp.c looks like

  if ((((longAt(foo->freeBlock)) & AllButTypeMask) < foo-
  >growHeadroom) && (foo->gcBiasToGrow > 0)) {
             /* begin biasToGrow */
             growSize = (((sqInt) (foo->growHeadroom * 3) >> 1)) -  
((longAt(foo-
  >freeBlock)) & AllButTypeMask);
             /* begin growObjectMemory: */
             foo->statGrowMemory += 1;
             limit = sqGrowMemoryBy(foo->memoryLimit, growSize);
             if (!(limit == foo->memoryLimit)) {
                 foo->memoryLimit = limit - 24;
                 initializeMemoryFirstFree(foo->freeBlock);
             }
             weDidGrow = 1;
         }


then you have the fix needed to use

Smalltalk setGCBiasToGrowGCLimit: 64*1024*1024.
Smalltalk setGCBiasToGrow: 1.

The 64*1024*1024.  value is chosen based on a guess. The proper value  
for your application can only be chosen by testing and observing how  
your server image responds to some particular test suite, or to  
production loading, whichever is less risky or mandated by your  
organization.
The other values

> SmalltalkImage current  vmParameterAt: 5 put: 8000.  "do an   
> incremental GC after this many allocations"
> SmalltalkImage current  vmParameterAt: 6 put: 4000.  "tenure when  
> more  than this many objects survive the GC"

are just double the defaults but could be adjusted higher depending on  
the acceptable delay for an incremental GC, also the "tenure when  
more  than this many objects survive the GC" might not need to be 50%  
of the allocation value it could be some other percentage of the total.
These values below could also be changed, but one would need to  
collect some GC statistical data and see if they require changing.
> Smalltalk vmParameterAt: 25 put: 24*1024*1024. "grow headroom"
> 	Smalltalk vmParameterAt: 24 put: 48*1024*1024.  "shrink threshold"


My point was the current default values were set in 1996 or so, and  
are NOT valid for a seaside server, plus the setGCBiasToGrow fixes an  
interesting performance issue with how the default grow logic deals  
with incremental GCs versus growth concerns.
On Nov 19, 2007, at 11:08 PM, chunsj at embian.com wrote:

> Hi,
>
> I've modified source code manually by referring http://bugs.squeak.org/view.php?id=6667 
> ,
> but I'm not sure whether modifying referred part is OK. It seems  
> that the code built without
> problem, and run correctly up to now :-)
>
> Should I regenerated all VM code instead of doing above?
>
> Thanks in advance.
>
> ----- Original Message -----
>   From: John M McIntosh <johnmci at smalltalkconsulting.com>
>   To: Seaside - general discussion  
> <seaside at lists.squeakfoundation.org>
>   Sent: 07-11-20 15:22:27
>   Subject: Re: [Seaside] seaside performance in Squeak
>
>  http://www.squeakvm.org/win32/
>
> you could talk to who ever built the current windows VM you have and
> see if it was built with VMMaker-tpr.63
> also see
> http://wiki.sq  
> Vhay5vcmcvc3F1ZWFrLzIxMDUNCg0KQSBWTU1ha2VyIGltYWdlIHRvIGJ1aWxkIGEgVk0g 
> bXVzdCBoYXZlIHRoZSBmaXhlZCBjb2RlIGFzIGRldGFpbGVkIGluDQpodHRwOi8vYnVncy5zcXVlYWsub3JnL3ZpZXcucGhwP2lkPTY2NjcNCg0KT3RoZXJ3aXNlIHRoZSB0dW5pbmcgaGludHMgd2lsbCBub3Qgd29yaw0KDQoNCk9uIE5vdiAxOSwgMjAwNywgYXQgNTo1MyBQTSwgY2h1bnNqQGVtYmlhbi5jb20gd3JvdGU6DQoNCj4gSGksDQo+DQo+IEkgdGhpbmsgdGhpcyBpcyB2ZXJ5IGdyZWF0IG5ld3MgYW5kIGNhbiBJIGdldCB0aGUgc291cmNlIG9yIGJpbmFyeSAgDQo+IG9mIFZNKHdpbmRvd3MpDQo+IGZvciB0aGlzPyBPciBzaG91bGQgSSBkbyB0aGlzIGJ5IG15c2VsZj8NCj4NCj4gVGhhbmtzIGluIGFkdmFuY2UuDQo+DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gICBGcm9tOiBKb2huIE0gTWNJbnRvc2ggPGpvaG5tY2lAc21hbGx0YWxrY29uc3VsdGluZy5jb20+DQo+ICAgVG86IFNlYXNpZGUgLSBnZW5lcmFsIGRpc2N1c3Npb24gIA0KPiA8c2Vhc2lkZUBsaXN0cy5zcXVlYWtmb3VuZGF0aW9uLm9yZz4NCj4gICBTZW50OiAwNy0xMS0yMCAwNTo1Mjo0OQ0KPiAgIFN1YmplY3Q6IFtTZWFzaWRlXSBzZWFzaWRlIHBlcmZvcm1hbmNlIGluIFNxdWVhaw0KPg0KPiAgSmFtZXMgaXMgYnVzeSBibG9nZ2luZyBvbiBzZWFzaWRlIHNxdWVhaywgVlcsIHJ1YnlvbnJhaWxzIHBlcmZvcm1hbmN
> lDQo 
> +IGFuZCBJJ2xsIG5vdGUgdGhhdCBhIGJpdCBvZiBTcXVlYWsgR0MgdHVuaW5nIGNhbg0KPiBpbXByb3ZlIHNxdWVhayBzZWFzaWRlIHRocnVwdXQgYnkgMTAwJQ0KPg0KPiBodHRwOi8vd3d3LmNpbmNvbXNtYWxsdGFsay5jb20vYmxvZy9ibG9nVmlldz9zaG93Q29tbWVudHM9dHJ1ZSZwcmludFRpdGxlPU1vcmVfU2Vhc2lkZV9UZXN0aW5nJmVudHJ5PTMzNzI5MjE5MjUNCg0KLS0NCj0gDQo9IA0KPSANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KSm9obiBNLiBNY0ludG9zaCA8am9obm1jaUBzbWFsbHRhbGtjb25zdWx0aW5nLmNvbT4NCkNvcnBvcmF0ZSBTbWFsbHRhbGsgQ29uc3VsdGluZyBMdGQuICBodHRwOi8vd3d3LnNtYWxsdGFsa2NvbnN1bHRpbmcuY29tDQo9IA0KPSANCj0gDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2Vhc2lkZSBtYWlsaW5nIGxpc3QNCnNlYXNpZGVAbGlzdHMuc3F1ZWFrZm91bmRhdGlvbi5vcmcNCmh0dHA6Ly9saXN0cy5zcXVlYWtmb3VuZGF0aW9uLm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vc2Vhc2lkZQ0KDQo=
> u

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