Dan Bron wrote: > there hasn't been a single instance of a memory leak in J's history [1].
Well, let me check again what I fixed on my J 4.05 post-release maintenance branch here: % cvs log -rj405-release |& awk '/^---/, /^===/' ---------------------------- revision 1.10.2.1 date: 2003-07-02 01:03:39 +0000; author: neitzel; state: Exp; lines: +1 -0; MFC: Plug a memory leak (shows up with +/@, i. 10). ============================================================================= % All official 4.05/unix versions had/have this (platform independent) leak. Windows versions from that era had that leak, too. Working on that port was quite difficult for me because many tests of the test suite (some 300 tests altogether) would drive my J porting boxes deep into swap space. An entire test run took more than 30 hours, and that with still three dozen tests not completing. This was mostly because many of the newer tests were dimensioned for machines with much more RAM than my trusty but old gear. It took quite a while to review the long-running tests. The task was to identify those cases where it was justified to make the test arrays smaller to fit the machine as opposed to tests which ate all memory because of a leak somewhere, as it should turn out eventually, alas, only after the 4.05/unix release. When all this work (inkl. the fixing of the leak) was done, the test suite could be passed again in under four hours wall-clock time and modest swap usage. (The leak is not present in 5.x and beyond.) I haven't been involved with J sources past 4.x but I was (and still am) quite pleased with that implementation. All in all, I'd say that Roger's memory management in the engine is sound. It's well engineered without being overly complex. Memorywise, I've seen this single one memory leak in contrast to a handful of alignment bugs. The latter are much easier to detect because the interpreter will simply crash and most of these bugs show up early when doing a port. (Again, because Roger did good work on the testsuite, too: there's a reason when a test array has shape 3 5 13 -- all primes.) The real test regarding memory leaks are long-running server applications, though, i.e. without any cheats such as nightly restarts. A few years after the much less known "X Windows System Version 10", X11 became very popular around 1987 along with Sun3s and other early workstations. With more and more people making use of the software, more and more memory leaks in the X server got detected, too. It took about three years (and the X11 developers were all smart guys!) of detecting holes and fixing them. The nasty leaks are the tiny ones, which have to accrue until they make your workstation slow down/freeze up after three weeks of trouble-free service. I am losing so many words about this because it provides another context for the leak you mentioned: > [1] Well, except for one very trivial memory leak, > http://www.jsoftware.com/pipermail/general/2003-June/013085.html > which, as I said, no "normal user" would ever encounter. (Essentially: "empty loop body causes 64-bytes leak"). As the follow-ups show, Roger plugged that one quickly (as usual), along with the question: "Does it matter at all?". Well, probably not in an interactive session or typical application software. But for J programmers who want to implement 24/7 services, such small leaks do matter. So, regarding Lau's original questions: I wouldn't be surprised if further memory issues would get detected. I *would* be surprised, though, if Roger wouldn't hunt it down within 48 hours once you present him a repeatable problem. He is exceptionally good in keeping his product spotless. Martin ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
