From: Sam S. <sd...@gn...> - 2000-12-21 17:51:35
|
As requested by a user, maybe we should add a variable *gc-verbose* (a la CMUCL), so that gar_col() would emit some message? E.g., (ecase *gc-verbose* ((nil)) ; no messages ((:global) (when (and gc-is-global (not (eq subr_self lisp:gc))) (format *standard-error* "~&global GC started in ~s, ~:d bytes collected~%" subr_self free))) ((t) (format *standard-error* "~&GC started in ~s, ~:d bytes collected~%" subr_self free))) This would be a great help in debugging. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> Whom computers would destroy, they must first drive mad. |
From: Bruno H. <ha...@il...> - 2000-12-21 18:08:23
|
Sam writes: > As requested by a user, maybe we should add a variable *gc-verbose* (a > la CMUCL), so that gar_col() would emit some message? Such messages are extremely annoying. Moreover, 10 to 5 years ago, there were lots of prejudices against garbage collection, because many users only knew Emacs' "Garbage collection" messages that often temporarily stopped the editor. It's a psychological effect. Someone (Paul Wilson?) said this prejudice could have been avoided if Emacs would instead have printed a message "NFS server not responding, still trying..." during every GC. > This would be a great help in debugging. In gdb, you can put a breakpoint at gar_col. Bruno |
From: Will M. <se...@es...> - 2000-12-22 11:28:48
|
On Th 21 Dec 2000 19:08:17 +0100 (CET) Bruno Haible <ha...@il...> wrote: > Sam writes: > > As requested by a user, maybe we should add a variable *gc-verbose* (a > > la CMUCL), so that gar_col() would emit some message? > > Such messages are extremely annoying. [...] It's more annoying to be wondering bemusedly what the computer is doing without having an easy way of finding out. Sam is proposing a variable that could and probably should be nil by default. (Applying gdb to clisp is not easy for someone just trying to learn Common Lisp, who might not even have the source code to clisp, or who might be unfamiliar with gcc & gdb.) I think Sam's right, because his proposal will cause minimal pain to people who want these messages and none to people who don't. -- Will Mengarini <se...@es...> Free software: the Source will be with you, always. |
From: Bruno H. <ha...@il...> - 2000-12-22 13:09:04
|
Will Mengarini writes: > It's more annoying to be wondering bemusedly what the computer > is doing without having an easy way of finding out. For doing that, there's only Ctrl-C or "ps". Your program might be stuck in a loop without memory allocation, then you won't see GC messages, or it may be stuck in a loop with allocation, then you will see them. So, you cannot draw any conclusion from the presence of the absence of the GC messages. For "finding out what the program is doing" a hotkey which prints a backtrace of the function calls to *debug-io* would be better. Bruno |
From: bruce <bru...@16...> - 2000-12-22 14:41:57
|
Will Mengarini wrote: > On Th 21 Dec 2000 19:08:17 +0100 (CET) Bruno Haible <ha...@il...> wrote: > > > Sam writes: > > > As requested by a user, maybe we should add a variable *gc-verbose* (a > > > la CMUCL), so that gar_col() would emit some message? > > > > Such messages are extremely annoying. [...] > > It's more annoying to be wondering bemusedly what the computer > is doing without having an easy way of finding out. Sam is > proposing a variable that could and probably should be nil by > default. (Applying gdb to clisp is not easy for someone just > trying to learn Common Lisp, who might not even have the source > code to clisp, or who might be unfamiliar with gcc & gdb.) I > think Sam's right, because his proposal will cause minimal pain > to people who want these messages and none to people who don't. Well, I'm just suggesting, or asking, ways to control the trigger condition when GC should occur. Of course, I have no objection to Sam's suggestion, but still don't know the answer to my question. My point is, if there are sufficient memory, CLISP may GC less frequently. Best! shouxun |
From: Bruno H. <ha...@il...> - 2000-12-22 15:15:22
|
bruce writes: > Well, I'm just suggesting, or asking, ways to control the trigger condition > when GC should occur. ... > > My point is, if there are sufficient memory, CLISP may GC less frequently. IMO, it should not be the user's burden to worry about GC tuning. Therefore I've put in a compromise between minimizing the number of GCs and minimizing the amount of unnecessary memory claimed by CLISP. You find the following comment in spvw.d: Garbage collection is invoked when the used space has grown by 25% since the last GC; until that point new pages are allocated from the operating system. The GC compacts the data in each page separately: data is moved to the left. Emptied pages are given back to the OS. If the holes then make up more than 25% of the occupied storage, a second GC turn moves objects across pages, from nearly empty ones to nearly full ones, with the aim to free as most pages as possible. I've tried various values for this percentage. 25% turns out to be a good compropise, giving less than 10% GC time even for memory intensive applications. Bruno |
From: <don...@is...> - 2000-12-22 15:44:08
|
> IMO, it should not be the user's burden to worry about GC > tuning. Therefore I've put in a compromise between minimizing the > number of GCs and minimizing the amount of unnecessary memory claimed > by CLISP. I must say you have succeeded and I appreciate having only experienced idle curiosity about clisp GC. And now you have even answered that. Well, to some degree. As usual, the answer only raises more questions. > You find the following comment in spvw.d: > Garbage collection is invoked when the used space has grown by > 25% since the last GC; until that point new pages are allocated from > the operating system. The GC compacts the data in each page separately: > data is moved to the left. Emptied pages are given back to the OS. > If the holes then make up more than 25% of the occupied storage, a second > GC turn moves objects across pages, from nearly empty ones to nearly full > ones, with the aim to free as most pages as possible. What do pages have to do with it? What do you save by compacting each page separately? Isn't there lots of stuff that crosses page boundaries? That must be done differently. And I know there's some sort (maybe several sorts?) of incremental GC. The parameters for that would actually be more interesting. |
From: Matt C. <cmc...@in...> - 2001-01-01 22:05:48
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: Sam> As requested by a user, maybe we should add a variable Sam> *gc-verbose* (a la CMUCL), so that gar_col() would emit some Sam> message? I'd be in favor of such a thing if it were NIL by default. (In CMUCL, I set *gc-verbose* to NIL, but occasionally set it to T. I believe that in 18c, the default has been changed from T to NIL.) -- Matt Curtin, Founder Interhack Corporation http://www.interhack.net/ "Building the Internet, Securely." research | development | consulting |
From: Matt C. <cmc...@in...> - 2001-01-10 02:03:15
|
>>>>> "Matt" == Matt Curtin <cmc...@in...> writes: Matt> I believe that in 18c, the default has been changed from T to Matt> NIL.) I believed incorrectly. I just tested CMUCL 18c, and the default for *gc-verbose* is still T. -- Matt Curtin, Founder Interhack Corporation http://www.interhack.net/ "Building the Internet, Securely." research | development | consulting |