Hello, having used LispWorks on a Notebook computer with Windows XP installed for a while now, I'm starting to suspect that LWW /may/ have subtle problems with XP's hibernation feature. Nothing reproducible, just random corruption now and then. If anybody else is using this kind of setup, do you have any problems? Alternatively, does anybody know of problems with long-running images in general, or with XP hibernation in general? Marcus
Marcus Breiing wrote: > having used LispWorks on a Notebook computer with Windows XP installed > for a while now, I'm starting to suspect that LWW /may/ have subtle > problems with XP's hibernation feature. Nothing reproducible, just > random corruption now and then. If anybody else is using this kind of > setup, do you have any problems? I'm using the same setup, but I have no problems that are related to XP hibernation or long-running images, as far as I know. Lispworks (I'm using LWW Professional 4.3.7) does crash sometimes though, but very rarely (say about once a month, and I use it every day) and not in a reproducible way. As for long-running images: I have written and delivered web-servers with Lispworks that easily keep running for months without any trouble (on Windows NT machines). Regards, Arthur Lemmens
What size addresses spaces can LispWorks and its GC deal with effectively? Effectively means no crashing, clean GCs, and acceptable performances.
"John C. Mallery" <jcma@ai.mit.edu> writes:
> What size addresses spaces can LispWorks and its GC deal with effectively?
Which version? I've tested LW 4.3.6 on linux with up to 1.4GB allocated.
Normal GC operation is always O.K., but the speed of full GC (mark-and-sweep
of gen. 2) tends to depend heavily not only on allocated memory but the
number of threads (this may be specific to my application).
In my server applications, I usually only have to run full GC 2 or 3
times a day. Here's an example from my log. This machine is an 1.6GHz
AMD Athlon:
("2004-04-01 00:10:19" "at-in-lisp" :DO-GC :STATS "freed 262916K in 4210 ms cpu time")
(Total allocation after this GC was: Total Size 463170K, Allocated 132613K)
In my experience, mark-and-sweep usually takes about 1-4 seconds on images
this large, but YMMV a lot! As long as I can schedule most global GCs to
happen in non-critical hours, I have no problems running 800MB LWL images.
--
(espen)
Thanks for your responses. I note that the phrase "in principle" appears in davef's description. Assuming, LW fits completely in physical memory, what are the "in practice" issues? Espen's experience for Linux under 4.3.6 is very encouraging. Are there other applications that have also tested large-address space operation? Does anybody find the GC problematic and resort to periodic clean restarts of lisp? (done for example with CMUCL for high-volume reservation systems) What plans are there to expand LW's address space utilization, for example, to take advantage of 64 bit Mac OS X on the G5 or other architectures?
"John C. Mallery" <jcma@ai.mit.edu> writes: > Does anybody find the GC problematic and resort to periodic clean restarts of > lisp? (done for example with CMUCL for high-volume reservation systems) Not me. I generally let the LW-based servers run for months. For one server I developed on Solaris 3-4 years ago, I needed to implement periodic memory defragmenting in addition to peridic mark-and-sweep. I see that this is now documented in Chapter 8 of the user guide (8.11 Controlling Fragmentation). -- (espen)
Hi, using COM/Automation under Windows, I came across something that LWW reported as #<general box, tag 00 217D5D84>. I'm not sure, but I think that this originally was a variant of type VT_DECIMAL, which LWW doesn't seem to support. Is there any deep reason why automation types VT_CY, VT_DATE and VT_DECIMAL aren't supported? Is it possible to get something out of that #<general box, tag 00 217D5D84> anyway? Regards Marcus Breiing