I dies with a MaxPermGen exception.
On Wed, Mar 4, 2009 at 3:27 PM, Chas Emerick wrote:
>
> That's a good point. Does such usage cause some failure, or is it a
> performance issue? I would think that prior generations' code
> (classes + classloader(s)) would get GC'd as necessary -- or is the
>
That's a good point. Does such usage cause some failure, or is it a
performance issue? I would think that prior generations' code
(classes + classloader(s)) would get GC'd as necessary -- or is the
number of created classloaders so significant as to hit some serious
limitation?
- Chas
Many people consider the use of eval in "normal" code to be bad style.
However, there are times when it is justified, such as genetic programming
or dynamic code loading. In these cases Clojure falls down without the
classloader trick.
On Wed, Mar 4, 2009 at 3:03 PM, Chas Emerick wrote:
>
> He
Hendrik,
I came across this issue with JNI libs some years ago, and also comes
up in the context of most app servers, which use a multitude of
classloaders to enable hot code reloading and such. The general
solution is to move your JNI lib into your boot classpath; in my
experience with
This was to fix a bug where new code (generated by (eval ...)) would never
get garbage collected and crashed some programs that used eval heavily. The
JVM has a limitation that it will never GC a loaded class, but can GC a
collection of classes referenced by a single classloader.
On Wed, Mar 4, 2
Without dedicated classloaders, temporary (dynamically created)
classes would leak (since there is no way to unload a class without
letting its classloader be garbage collected). This might or might not
be the reason why Clojure uses many classloaders.
--~--~-~--~~~---~
I think it is the best way to load and discard lots of dynamically-loaded
and in fact dynamically-generated classes.
Joshua
On Wed, Mar 4, 2009 at 5:21 PM, Hendrik wrote:
>
> Hi,
>
> I got a question: Clojure seems to create poopillions of
> DynamicClassLoader instances. Why does it do that? Cou
