If you look at the bytecode for the closures, you'll see that the Var that *ns*/a points to is resolved at <clinit> time, and the Java reference is stored as a static final class member. That's a small use of additional permgen.
In your example, my-generator isn't the concern. It's the call to my- generator that creates functions, each of which creates bytecode, is loaded as a class, then is instantiated, and finally invoked. That temporarily uses permgen. There should be no problem collecting permgen in this trivial example. However, more complex scenarios will cause classes to live far beyond you would expect. If there is a leak or long-lived object, you'd rather it be in the regular heap instead. My point in the other thread was more of a question of using closures at all vs. not using closures. All functions lead to a loaded class, which by definition uses permgen. Unless there's a real win in terms of design or maintainability, you should use regular functions and just pass in your state/identity. The use case in the other thread was a bad one as far as using closures go; I was recommending against that. On Nov 15, 2:52 pm, Ken Wesson <kwess...@gmail.com> wrote: > In another thread, someone just indicated that a closed-over variable > chews up permgen. Is this true? > > I had been under the impression that keywords didn't get > garbage-collected, so runtime generation with (keyword foo) ought to > be used sparingly, but that was it. > > Perhaps the scenario was something along the lines of > > (defn make-generator [] > (let [a (atom 0)] > (fn [] (swap! a inc) @a))) > > (def my-generator (make-generator)) > > user=> (my-generator) > 1 > user=> (my-generator) > 2 > user=> > > In this case, a closed-over atom is referenced by a function that's > bound to a global var, my-generator. This won't be garbage-collected > so long as my-generator isn't un/redef'd. Even so it shouldn't be > permgen, technically speaking; just indirectly referenced by a loaded > class and so ineligible for GC by more "ordinary" criteria. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
