krovetz@cs.umass.edu (Bob Krovetz) (01/23/91)
I'm using a micro-explorer, running release 6.31, and I'm having a problem with my swap space running low. The storage continues to accumulate as I use the system, but I'm not sure what's taking up so much space. I start out with a load band of about 60MB (I have a number of large data structures included in it). After I've used the system for several days (sometimes a week), I find the dump size has increased to about 120MB, and I get messages about `swap space low'. I did a (si:describe-all-areas) before I rebooted, and compared that with the results right after rebooting. The areas that seemed to be causing the problem are: P-N-STRING, and PDL-AREA. There were also increases in WORKING-STORAGE and PERMANENT-STORAGE, but they weren't as big a factor as the other two. Does anyone have any suggestions for how I can determine what is taking up this storage? Is there any way to `layer' storage allocation - i.e., tell the system to allocate all storage from now on in a separate layer, and then `pop the stack' when the storage gets low? I don't want to explicitly refer to areas on each interaction; I just want to say something like `push storage area' and `pop storage area'. Thanks, Bob krovetz@cs.umass.edu
Rice@SUMEX-AIM.STANFORD.EDU (James Rice) (01/25/91)
>> I'm using a micro-explorer, running release 6.31, and >> I'm having a problem with my swap space running low. >> The storage continues to accumulate as I use the >> system, but I'm not sure what's taking up so much >> space. I start out with a load band of about 60MB (I >> have a number of large data structures included in >> it). After I've used the system for several days >> (sometimes a week), I find the dump size has increased >> to about 120MB, and I get messages about `swap space >> low'. Lasting a week sounds pretty good to me, given how storage-leaky most code is. >> I did a (si:describe-all-areas) before I >> rebooted, and compared that with the results right >> after rebooting. The areas that seemed to be causing >> the problem are: P-N-STRING, and PDL-AREA. There were >> also increases in WORKING-STORAGE and >> PERMANENT-STORAGE, but they weren't as big a factor as >> the other two. I'm no expert on this, but I had a quick look. PDL-AREA appears to be the area in which stack groups are consed. One might suspect that you (or someone else) are doing a lot of process-run-functions and that the stack groups for the processes that are being consed are not being released. The P-N-STRING area is the one in which print names are consed. It would appear, therfore that you are probably interning a lot of symbols. If you try to intern a symbol then it ends up in SYS::MAKE-SYMBOL-IN-AREA. If the pname string you passed to it isn't aready in the P-N-STRING area then it is copied into it. Maybe you can use something other than symbols for whatever you are doing. >> Does anyone have any suggestions for >> how I can determine what is taking up this storage? >> Is there any way to `layer' storage allocation - i.e., >> tell the system to allocate all storage from now on in >> a separate layer, and then `pop the stack' when the >> storage gets low? I don't want to explicitly refer to >> areas on each interaction; I just want to say >> something like `push storage area' and `pop storage >> area'. >> Thanks, Bob >> krovetz@cs.umass.edu TI doesn't provide any good tools for this. One thing I've done is to cons my own area and then binr default-cons-area to it around certain points in my code and watch the effect in Peek. However, this doesn't help if the system is consing into specific areas as it is in your case. Doing a bunch of who-calls on the area names can be revealing. The following are the who-calls for your two area in the sys package. P-N-STRING: SYS::INITIALIZE-UNFASL-TABLE SYS::MAKE-SYMBOL-IN-AREA SYS::INITIALIZE-FASL-TABLE PDL-AREA: SYS::LOCATION-FUNCTION-SPEC-HANDLER SYS::FUNCTION-SPEC-DEFAULT-HANDLER If you have a good idea of what you're consing then you might want to use temporary areas. You can do something like this: (defvar *my-area* (sys:make-area :name 'search-and-replace :representation :structure :gc :temporary :force-temporary t)) ;;; Then (let ((sys:default-cons-area *my-area*)) ;;; do your consing dynamically inside this form. ...) ;;; Once you're sure you're through with ALL of the ;;; stuff you consed: (sys:reset-temporary-area *my-area*) You may also have to give a few :area args to any system functions that pick their own areas. This strategy does NOT work for functions. If you want to cons and compile functions on the fly and then flush them then you need to do some more serious frobbing. If you need the patch for this drop me a line. I haven't got it on this machine, but can get it easily. Rice.