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<javascript:> > > 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<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.
