You might want to give Eclipse MAT (http://www.eclipse.org/mat/) a try. It can be used as a standalone tool.
Julien Le mardi 17 septembre 2013 12:45:41 UTC-3, Brian Craft a écrit : > > 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 >>> --- >>> 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. >>> >> >> -- -- 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.
