Just to follow up, I did some tests with a simple project that had core.async, component, and tools.namespace. I ran a REPL and in it had a doseq loop calling (refresh) over and over. In another terminal, I had a "watch -n 1 "touch src/test/core.clj" repeating to update the file. The core file created some core.async channel and defined a component using defrecord. I then opened JVisualVM and watched the PermGen space and Class graph over time. At least with this simple setup, the PermGen space was freeing nicely and the number of loaded classes would go down as well upon the frees of PermGen space.
I had Oracle JDK 1.7 on this test VM, so I don't know if that's a factor. Either way, I suspect it's an interaction of parts of your system with something being cached along the way that might be causing the OOME. On Thursday, December 18, 2014 1:07:54 PM UTC-5, Steven Yi wrote: > > I received a message from Moritz that everyone is on openJDK 1.7. I was > curious and looked into this a little bit. I found one older thread from > this forum [1] that mentioned PermGen and OutOfMemory. The following are > some notes that will hopefully help here. > > Regarding the exception: > > Caused by: java.lang.OutOfMemoryError: PermGen space, > compiling:(cljs/core/async/impl/ioc_macros.clj:348:1) > > that line of ioc_macros.clj uses a defrecord. That'd make sense that that > would trigger the OutOfMemory as that would generate classes to go into > PermGen. > > Now, the problem in analyzing this is that it might be one part of the > system is holding references to older classes and surviving reloads, but > other parts are loading/unloading just fine. If the one part is creeping > up in size, you might get the PermGen OOME because something triggered it, > but what triggered it might not be the root cause. Also, it might be > something in one of the libraries you're using, but it could also depend on > what you have evaluated in your REPL name space. It might also happen if a > thread is still alive through a reload, as mentioned in [2]. > > One other question: Are you using core.async on the server-side of your > application? I wonder if there is a possible situation here where parked > IOC threads from a previous app load are being kept around. I don't know > core.async well enough to know if/when parked threads go out of scope, but > I thought this could be a possibility. > > [1] - https://groups.google.com/forum/#!topic/clojure/LGZlC5BX92A > [2] - http://java.dzone.com/articles/what-permgen-leak > > On Wednesday, December 17, 2014 7:05:36 PM UTC-5, Steven Yi wrote: >> >> Out of curiosity, are you colleagues perhaps using Java 8 JDK's? I saw >> your message mentions JDK 7 and PermGen was removed in Java 8[1]. >> >> [1] - http://www.infoq.com/articles/Java-PERMGEN-Removed >> >> On Wednesday, December 17, 2014 12:41:29 PM UTC-5, Moritz Ulrich wrote: >>> >>> >>> Hello, >>> >>> I'm getting the following error while working on a Clojure(Script) REPL >>> on a middle-sized project after some time. None of my colleagues seem to >>> be able to reproduce it. I'm not able to reproduce it on other projects >>> either. >>> >>> Caused by: java.lang.OutOfMemoryError: PermGen space, >>> compiling:(cljs/core/async/impl/ioc_macros.clj:348:1) >>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6651) >>> at clojure.lang.Compiler.analyze(Compiler.java:6445) >>> at clojure.lang.Compiler.analyze(Compiler.java:6406) >>> at >>> clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782) >>> at >>> clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6100) >>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6644) >>> at clojure.lang.Compiler.analyze(Compiler.java:6445) >>> at clojure.lang.Compiler.analyze(Compiler.java:6406) >>> at >>> clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:5782) >>> at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5217) >>> at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3846) >>> at clojure.lang.Compiler.analyzeSeq(Compiler.java:6642) >>> at clojure.lang.Compiler.analyze(Compiler.java:6445) >>> at clojure.lang.Compiler.eval(Compiler.java:6700) >>> at clojure.lang.Compiler.load(Compiler.java:7130) >>> at clojure.lang.RT.loadResourceScript(RT.java:370) >>> at clojure.lang.RT.loadResourceScript(RT.java:361) >>> at clojure.lang.RT.load(RT.java:440) >>> at clojure.lang.RT.load(RT.java:411) >>> at clojure.core$load$fn__5066.invoke(core.clj:5641) >>> at clojure.core$load.doInvoke(core.clj:5640) >>> at clojure.lang.RestFn.invoke(RestFn.java:408) >>> at clojure.core$load_one.invoke(core.clj:5446) >>> at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) >>> at clojure.core$load_lib.doInvoke(core.clj:5485) >>> at clojure.lang.RestFn.applyTo(RestFn.java:142) >>> at clojure.core$apply.invoke(core.clj:626) >>> at clojure.core$load_libs.doInvoke(core.clj:5524) >>> at clojure.lang.RestFn.applyTo(RestFn.java:137) >>> at clojure.core$apply.invoke(core.clj:626) >>> at clojure.core$require.doInvoke(core.clj:5607) >>> at clojure.lang.RestFn.invoke(RestFn.java:408) >>> at cljs.analyzer$eval21264$fn__21266.invoke(analyzer.clj:1190) >>> at clojure.lang.MultiFn.invoke(MultiFn.java:249) >>> at cljs.analyzer$analyze_seq.invoke(analyzer.clj:1490) >>> >>> I'm using lein-repl in combination with weasel to work on the server- >>> and client-side (cljs) of this project. The server-side uses the >>> component-design by stuartsierra, though the permgen issues don't seem >>> to correlate to calls to (reload). >>> >>> $ lein version >>> Leiningen 2.5.0 on Java 1.7.0-u65 OpenJDK 64-Bit Server VM >>> >>> Some of the dependencies (I suspect some of them are responsible): >>> >>> [org.clojure/clojure "1.6.0"] >>> [org.clojure/core.async "0.1.346.0-17112a-alpha"] >>> [com.stuartsierra/component "0.2.2"] >>> [org.clojure/tools.namespace "0.2.7"] >>> [lein-cljsbuild "1.0.3"] >>> [cider/cider-nrepl "0.8.1"] >>> >> -- 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/d/optout.
