Re: [Squeak-VMdev] Re: GC improvements

[Andreas R. <and...@gm...>]

John,

> Well the VM change won't get triggered unless you supply a GC semaphore 
> as part of doing active monitoring and memory tuning. No active 
> monitoring and memory tuning then no new logic is run and we default to 
> the historical behavior. My original point was that the growth part is  in 
> the VM, the GC trigger companion to the logic is in the image. The  VM 
> part will always run, the image part could choke. Thus a suggestion  to 
> move it into the VM.  However I'm leery about doing that since  perhaps 
> you don't want to say do a GC after N MB of growth, rather do  it after a 
> build a teapot, or after N http requests, having it in  smalltalk makes it 
> much easier to tinker with.

Okay, now I see your point. I was confused by the intention of having 
the -seemingly unrelated- GC semaphore be the indicator for having the image 
in control of memory growth behavior (thus my question about what the GC 
sema has to do with growing the OM).

This makes sense now, and although I'd still like to be able to have more 
reasonable behavior without a monitoring process I'm fine with having the 
change done in this way.

Effectively this means that older images running on VMs with these changes 
exhibit precisely the previous behavior and running the GC monitor on top of 
a new VM would put the monitor in control. Sounds good.

> I will note that in VisualWorks the oldspace GC logic is a separate 
> process (or two) and if they die your VW application will soon run out  of 
> memory since  those Smalltalk processes control how oldspace  incremental 
> logic is run.   So leaving the logic in Smalltalk isn't an  outrageous 
> suggestion, but it's not fail safe.

I didn't think it would be outrageous - the thing I worried about is running 
an image on top of a VM which exposes unbounded growth behavior. (and I 
don't care whether VW dies if the controller process dies ;-)

> What I could do is integrate your changes with mine over the weekend,  and 
> unless you want to take on that task?

If you can find the time this would be great (I may or may not get around to 
it).
To summarize:
* Use gcSemaIndex instead of TheGCSemaphore for compatibility
* Trigger growth logic in tenuring upon presence of gc sema
* Remove the stats from the inner loops of the GC logic.
Is this it?

Cheers,
  - Andreas