Fwd: [Vm-dev] VM stability issue on unix

I've recently brought up the following issue on the VM mailing list,  
but got no reply so far for whatever reason...

In short, the problem is that the unix VM blocks after the memory  
consumption exceeds about 120MB. I think its a critical bug, likely  
affecting many Seaside users who deploy on unix systems.

I've filed the following Mantis report: http://bugs.impara.de/ 
view.php?id=4709

Adrian


Begin forwarded message:

Ok, if you can forward this to the Seaside list that would be good.

It's possible that you run in the GC bug that I talk about  in

http://minnow.cc.gatech.edu/squeak/3710

Basically when the GC logic approaches a decision to grow memory it  
first does a full GC event, if that GC event
return just enough memory, then it will not grow the memory used by  
the VM, however the amount of space required to
do anything is insufficient, and after a few message sends we again  
try to grow memory and do a full GC and recover
just enough bytes not to force the grow.  Repeat a few million  
times...  CPU goes to 100% always in GC logic no real work happens,  
normally
it only interates a few thousand, 10 or 100 thousand times, sucking  
CPU uselessly...

First of all you need a new Unix VM build with the latest VM maker  
that has the needed code and primitive API.

The look at my change sets.

Somewhere at startup time you need to invoke:

Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024.
Smalltalk setGCBiasToGrow: 1.
GCMonitor runActive.

setGCBiasToGrow alters the VM to grow versus doing a full GC and  
deciding to grow.

setGCBiasToGrowGCLimit alters the limit to force a full GC after we  
grow by this much to ensure growth is not unbound.

The GCMonitor class allows you to collect statistical data from the  
GC, either at the end of each GC cycle, or on a timer.
This data can be then saved to a file for review to allow one to  
intelligently adjust the GC parms .
The supplied GCMonitor more a template than a finished product.


It more importantly much like VisualWorks looks at some of the data  
and makes runtime decisions like:

a) force a tenure if we find we are doing too much root table  
scanning, this happens if you allocate a large collection and it gets  
put in to
the root table, when looking for intergenerational references we scan  
the entire million entry object since the GC knows the object  
contains a pointer to an object that is a root, but which one?  
Historically people would force a GC after allocating a large  
collection to avoid this problem.   However if I say

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

where we look at the mark count total versus the allocation count  
total we can decide if we need to force a tenure to solve this  
problem automatically.

The code also has some example code (not used) to  alter the size of  
the allocation and tenure targets to adjust a GC cycle to 1 millisecond.
Those values where picked, oh 10  years back for 25 Mhz machines, I'd  
guess 3Ghz machines can increment GC much more memory.

        (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"].! !


I'll further note that Sophie has a SophieMemoryPolicy now to tune  
Sophie GC behavior, perhaps SeaSide requires a SeasideMemoryPolicy to
best tune the GC at runtime like more sophisticated VMs, like  
VisualWorks?

Lastly I'd welcome a statistical file or two to look at from a large  
seaside image just to understand what's happening, and as always for  
a fee I
can perform a GC memory audit on any large scale VW or Squeak  
application.


On 5-Sep-06, at 3:06 AM, Adrian Lienhard wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===