[developers] Ubuntu+LKB 17: lots of gc; [incr tsdb()] podium freezes frequently
oe at ifi.uio.no
Sat Jan 18 00:07:32 CET 2014
> We're using Ubuntu+LKB17 in Ling 467 quarter, and I've noticed some odd
> behavior: first of all, the LKB seems to be doing way more gc than I expect
> while loading a small Matrix-derived grammar, especially if I've kicked off
> the [incr tsdb()] podium. Another quirk is that before kicking off [incr
> tsdb()], the gc doesn't result in any messages being printed to the
> *common-lisp* buffer, just a flickering "gc" in the bar at the bottom. Once
> I have, however, I get the messages (see attached buffer).
the second part of what you report is expected: [incr tsdb()] makes
the built-in garbage collector more verbose, i.e. print a message for
each gc() call.
as regards general gc() frequency, i do not recall any changes in
the LKB or [incr tsdb()] in this neighborhood in recent years, so i
wonder whether what you see is an effect of changes in any one
of (a) the virtual machine configuration, (b) the Lisp system , or
(c) the build process. as it happens, you control all of the above
at UW: david, would you expect differences in memory setup or
i must confess that i would like to think the perceived increase in
gc() frequency after loading [incr tsdb()] is just the effect of the
system being more verbose about gc()s now. when there is no
[incr tsdb()] activity, it should not contribute to memory usage.
> The other thing I've noticed is that the [incr tsdb()] podium is freezing
> frequently. If I can put together a recipe to reproduce that, I'll report
> it. The window can be closed by clicking the x and then reopened with M-x
> itsdb, and then it works fine, for a while.
> Any ideas what might be going on here?
these are difficult to debug, of course, locally and even more
so remotely. by freezing, you mean completely irresponsive
to keyboard or mouse events? is it showing a gc() cursor at
that point? if so, does it respond to pressing Escape?
if not the above, i dimly recall there were Tcl/Tk issues with
some variants of XIM that could cause a complete freeze.
this is the kind of thing that conceivably could change from
one virtual machine build to the next, but from memory many
years have passed, i think, since we last encountered this
problem. there might even be something in the archives of
the ‘developers’ list?
sorry, i wish i could be more helpful! oe
+++ Universitetet i Oslo (IFI); Boks 1080 Blindern; 0316 Oslo; (+47) 2284 0125
+++ --- oe at ifi.uio.no; stephan at oepen.net; http://www.emmtee.net/oe/ ---
More information about the developers