On Tuesday, May 28, 2013 1:01:46 PM UTC-7, Ben Mabey wrote: > On 5/28/13 1:05 PM, Lee Spector wrote: > > On May 28, 2013, at 2:40 PM, Ben Mabey wrote: > > The flag is a system property: > "-Dclojure.compiler.disable-locals-clearing=true". So you can add that > string to your project.clj's :jvm-opts if you are using lein. This will, of > course, slow down your program but when I've used it in the past it hasn't > made it unusable for development. > > Thanks for the project.clj specifics Ben. > > It still isn't clear to me if/how I could then look at the locals after > hitting an unexpected exception. Perhaps Cedric's strategy described a couple > of messages back (which I didn't fully understand) would work here? But from > the lack of followup to this post > http://comments.gmane.org/gmane.comp.java.clojure.swank-clojure.devel/106 -- > I wonder if it still won't work when hitting unexpected exceptions. > > > To do this I have been using nrepl-ritz's 'M-x > nrepl-ritz-break-on-exception'. If you are using emacs and haven't looked > into ritz I would highly encourage taking the time to do so. It is > painless to install these days and you can watch a nice presentation on it ( > https://github.com/pallet/ritz/tree/develop/nrepl#additional-resources). > If you aren't using emacs then I don't have any suggestions for you. :( > > Also, I guess I don't understand what locals clearing is in this context, but > why would this slow things down? If it's just preventing the clearing of > locals when handling an exception then I'd expect it to have no effect except > during an exception... Do you mean that it'll slow down code that does a lot > of "exception" handling in circumstances that aren't really exceptional? Or > will this flag do something very different than what I'm thinking, like > causing all locals everywhere to be retained forever? That'd cause problems > worse than just slowdowns, I would think. > > It would slow things down in that more things wouldn't be allowed to be > GCed as soon as they would be with locals clearing (the usual culprit being > lazy seqs). Unfortunately, I don't know enough of the details of how and > when locals clearing works to give you more details. So I'd love to hear a > better explanation from someone who knows. >
The principal problem of disabling locals-clearing is not "slowing things down", but rather causing perfectly reasonable code to consume unbounded memory. For example, consider: ((fn [xs] (nth xs 1e8)) (range)). With locals clearing, the compiler makes sure that xs is available for GC as it is being processed, so that the working-set size is small. If locals clearing is disabled, the local reference xs is kept around in case a debugger wants to look at it, and so the head of xs is being held while it is realized, meaning a hundred-million-element range must be kept in memory until the function call completes. It's definitely useful to be able to disable locals-clearing temporarily while debugging, but doing so in any kind of production app would be a disaster. -- -- 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.
