Awesome, thanks! I'd forgotten about the hits for MAT, because I don't use eclipse, and I had not found YourKit.
On Tuesday, September 17, 2013 9:13:17 AM UTC-7, Andy Fingerhut wrote: > > I didn't notice before posting my previous message that YourKit also has a > free "for open source project use only" license for their tool. Click on > the "Open Source" or "License Comparison" tabs on this page: > > http://www.yourkit.com/purchase/index.jsp > > > On Tue, Sep 17, 2013 at 8:56 AM, Andy Fingerhut > <andy.fi...@gmail.com<javascript:> > > wrote: > >> Some of the hits point at commercial tools, which you didn't mention. >> >> I've heard positive comments about YourKit in the past. It is >> commercial, but it looks pretty easy to get a 15-day evaluation license. I >> haven't used it, but it claims to have some features to aid in detecting >> and analyzing memory leaks: >> http://www.yourkit.com/docs/80/help/memory_leaks.jsp >> >> I also saw hits for a tool called plumbr. I have no information about >> it, good or bad. >> >> Andy >> >> >> >> >> On Tue, Sep 17, 2013 at 8:45 AM, Brian Craft <craft...@gmail.com<javascript:> >> > wrote: >> >>> I did, of course, spend a lot of time with google before posting. All of >>> the hits point to jconsole, jmap, and visualvm. None of these tools work >>> reliably. They hang, they crash, they spit up errors, they generate useless >>> results. You'll note in another thread this morning another developer >>> having jmap and visualvm barf on them. It's not an isolated incident. >>> >>> >>> On Tuesday, September 17, 2013 8:21:14 AM UTC-7, Andy Fingerhut wrote: >>> >>>> Another possibility: The people who know aren't reading this thread. >>>> >>>> I'd tell you if I knew, but I haven't needed to track down a problem >>>> like this for several years, and forgotten whatever tool I used at the >>>> time >>>> (it was probably jmap). >>>> >>>> Suggestion: Google search "java memory leak" and see what tools and >>>> techniques people suggest in articles they write on the topic. >>>> >>>> Andy >>>> >>>> >>>> On Tue, Sep 17, 2013 at 8:07 AM, Brian Craft <craft...@gmail.com>wrote: >>>> >>>>> >>>>> >>>>> On Thursday, September 12, 2013 7:47:02 PM UTC-7, Cedric Greevey wrote: >>>>> >>>>>> On Thu, Sep 12, 2013 at 3:33 PM, Andy Fingerhut <andy.fi...@gmail.com >>>>>> > wrote: >>>>>> >>>>>>> I have just added some discussion of this on ClojureDocs.org for the >>>>>>> function clojure.core/subs, and references to that discussion for >>>>>>> several >>>>>>> other Clojure functions that I am pretty sure are affected, e.g. >>>>>>> re-find, >>>>>>> re-seq, re-matches, clojure.string/split, replace, replace-first >>>>>>> >>>>>> >>>>>> We know with certainty that clojure.string/split is affected. Also, >>>>>> the OP's question about how to use tooling to track down similar leaks >>>>>> in >>>>>> the future does not appear to have been satisfactorily answered as of >>>>>> yet. >>>>>> >>>>> >>>>> cricket, cricket, cricket... >>>>> >>>>> ;) >>>>> >>>>> Is there really no working tooling for the jvm? >>>>> >>>>> The string thing bothers me less than the problem of seq heads. It is >>>>> ridiculously easy to create a memory leak with a seq, and desperately >>>>> hard >>>>> to track one down. I would be surprised if most clojure apps were not >>>>> leaking memory somewhere, in places that go unnoticed until a >>>>> sufficiently >>>>> large input fills the heap. >>>>> >>>>> I wonder if a static analysis approach could identify code that >>>>> appears to retain a seq head to no effect. >>>>> >>>>> -- >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To post to this group, send email to clo...@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+u...@**googlegroups.com >>>>> >>>>> For more options, visit this group at >>>>> http://groups.google.com/**group/clojure?hl=en<http://groups.google.com/group/clojure?hl=en> >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Clojure" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to clojure+u...@**googlegroups.com. >>>>> >>>>> For more options, visit >>>>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>>>> . >>>>> >>>> >>>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com<javascript:> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com <javascript:> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
