|
From: John M M. <jo...@sm...> - 2005-01-19 22:57:41
|
On Jan 19, 2005, at 2:38 PM, Andreas Raab wrote: > John, > >> You miss the point that after N MB of memory growth, we do a full GC >> event. >> >> The logic to do the full GC is either in the smalltalk code running as >> active memory monitoring, or can be moved into the image. > > My criticism here is that the *default* without running that extra > code is not sensible. In other words, without active monitoring and > memory tuning you will indeed run out of memory. And that's just not > acceptable - there are plenty of people who will want to run a VM with > as little overhead as possible. 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. 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. What I could do is integrate your changes with mine over the weekend, and unless you want to take on that task? > -- ======================================================================== === John M. McIntosh <jo...@sm...> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== === |