No, it won't force a GC. But it should be eligible for GC, if that's what you mean. Hopefully the memo cache will stay in the generation-zero nursery, in which case it will incur effectively no GC cost since the nursery collector runs in time O(live objects in nursey) rather than O(total objects in nursery).
In a Platonic paradise, the cache could even be allocated and freed without any GC involvement whatosever due to the magic of HotSpot's escape analysis. But that seldom works as widely in practice as one might hope and I expect it wouldn't in this example. -Per On Fri, Mar 19, 2010 at 1:05 PM, Greg Fodor <gfo...@gmail.com> wrote: > Ah, I think I have the solution: > > (defn foo [] > (let [bar-memoized (memoize bar)] > ; Do stuff with bar-memoized > )) > > Seems to work -- to verify, this will GC the memoized cache for bar > after each call to foo, right? > > On Mar 19, 1:56 am, Greg Fodor <gfo...@gmail.com> wrote: >> Hi there -- I am looking for a solution to a particular memoization >> pattern. I have a function foo that is the entry point of a caller >> that makes many thousands of calls to a function bar. In calling foo, >> bar will be called with many different args but there are many >> repeated calls to bar with the same args. >> >> I would like to memoize bar such that the memory used for memoization >> is GC'ed at the end of the call to foo, and additionally the cache >> used for memoization is thread local (so no need for heavyweight >> synchronization tools like atoms, etc.) In Ruby, I would implement >> this as a simple local hash with the ||= operator through each >> iteration of a loop inside foo that calls bar. >> >> This seems like a fairly common case, so I was wondering if there is >> an idiom/API to do this for me easily. Alternatively, my first guess >> is to write a macro that memoizes the function but allows the macro >> caller to name a dynamic var for the cache which can then be thread- >> locally bound from the caller side. When the caller var falls out of >> scope it should be GC'ed. If this makes sense, let me know. >> >> Thanks! > > -- > 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 > > To unsubscribe from this group, send email to > clojure+unsubscribegooglegroups.com or reply to this email with the words > "REMOVE ME" as the subject. > -- 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 To unsubscribe from this group, send email to clojure+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
