(defop foo req
(let x <something that allocates a bunch of memory>
nil))
does this leak memory? (Using, of course, the trick the other people mentioned of forcing a garbage collection so that you can find out if you're really leaking memory). If this does leak memory, then your "<something that allocates a bunch of memory>" is storing a reference to all or part of your data somewhere outside of the defop and that's your problem. If you want proof that it's the "something" that's leaking memory and it's not the fault of srv.arc, turn the defop into a regular function and see that calling it still leaks memory.
If the above doesn't leak memory, then something in your "..." is doing it. Add "..." stuff back in until you start leaking memory again, and you've found your culprit.
Another question is are you using Arc 3.1 or Anarki? I haven't looked at Anarki, so I don't know what if anything it might or might not be doing differently, but you might want to ensure that you aren't returning some large object from the defop. In Arc 3.1, I could be wrong, but just reading through the code it looks like the return value would get discarded in the whilet loop in handle-request-thread, but maybe Anarki is doing something differently.
I finally figured it out. Inside "..." is an flink whose continuation function references x. srv.arc's default threshold for harvest-fnids is very large, so my memory was getting completely consumed before any fnids could be harvested; hence the references to each x were lingering, and mzscheme couldn't consider them garbage.
My workaround is to have foo make a call to harvest-fnids with a calculated threshold much lower than the default, and now memory consumption isn't getting out of hand. Thanks for everyone's help!
