Erik, what you said seems to make sense. So the question now is, since a new classloader is started during each eval at the repl, does that mean that it is closed after each repl statement? This seems to be the case because after requiring a namespace in a previous command at the repl, I can no longer reload that namespace with (require 'foo :reload). However, because I am holding on to that namespace (as I can access anything in that namespace I required), I feel that it isn't completely unloaded. The natural follow up question would be, does unloading the namespace required earlier then unload the classloader? And, how does one test this? How does one obtain the hierarchy of classloaders given you don't have references to the children.
Jason, well I have been studying classloaders and have implemented my dynamic loading of jars scheme. I'm not actually redefining any new classloaders but just using the existing one used by clojure, which is an extension of the URL classloader. I add new jars with the addURL method. From my tests, it works just fine. I am able to start with just clojure in my classpath from commandline, then I can freely add jars like contrib or swank-clojure and load the namespaces from them. >From what I see, implementing a nailgun like server where applications are unloaded at runtime would be more difficult to design given the holding references problem, which is only exacerbated by the fixed permgen size. From what I've researched, unloading classes can be tricky, which is why I have held off implementing those features, however if its relatively feasible, I feel I should take care of this in one go. Jason, you mentioned performance depending on classloader usage, but what could cause differences besides the memory leak problem as described in this link http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java On May 25, 12:40 am, Jason Smith <ja...@lilypepper.com> wrote: > Classloaders are generally additive. The system classloader pulls in > standard Java libraries and anything else you specify on the command > line. Then you can add classloaders, and they delegate back to the > parent classloader as a default behavior. When you want to get rid of > the JAR references for a classloader, you throw the whole thing away > and start new. Anything you want to save, you need to serialize and > recreate. > > There are ways to change the default behavior of classloaders, but you > really have to know what you are doing or you'll get yourself into > trouble. > > Before you go too far with a design, study up on how classloaders > work. They really are almost magical, but there are limitations. If > you use them correctly, you get incredible performance, and if you use > them incorrectly, performance can be pretty poor. Plan to do lots of > experimentation, and best of luck! > > On May 24, 9:06 am, Brent Millare <brent.mill...@gmail.com> wrote: > > > > > I am creating another dependency management system that using dynamic > > compilation to load dependencies during runtime. My actual issue is I > > needed to reconstruct the new effective classpath which should include > > the classpath given (from (System/getProperty "java.class.path")) at > > the commandline and the URLs given when the dependency management > > loads new jars (.getURLs (.deref (clojure.lang.Compiler/LOADER))). I > > suppose I don't need to maintain a reference to the many classloaders > > if I simply maintain a listing of all URLs in something like a > > reference, is that correct?. Also, I suppose the issue now is that in > > the future when I may want to support unloading of classes to > > facilitate faster startup of applications, like in the design of > > nailgun, I would need to create explicit semantics that would need to > > be used to unload classes because URLs would not automatically be > > removed from my maintained reference, do you agree? > > > Best, > > Brent > > -- > 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 > athttp://groups.google.com/group/clojure?hl=en -- 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
