On Sep 14, 6:26 am, MikeM <[EMAIL PROTECTED]> wrote:
> If you haven't already seen it, an interesting post from Charles
> Nutter on implementing dynamic languages on the
> JVM:http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html
>
> Nutter mentions a possible OutOfMemory condition that can occur due to
> filling the PermGen part of the heap with class information, due to
> the fact that JRuby emits lots of classes. Seems like Clojure would
> have the same issue, but I haven't experienced it. Since I have
> started using Clojure in long-running webapps, with the intent of
> making additions and changes on the fly, should I be concerned about
> PermGen with Clojure?
Nope. While Clojure does use a class per function, and thus
potentially more classes than a Java app might, if it had the same
number of methods, the difference is not that great, as there is far
more function reuse in Clojure, and thus fewer functions than you
would have methods.
More to the permgen point, Clojure does not do any dynamic ephemeral
class creation. It creates classes for the functions you define.
Period.
In particular Clojure does not:
- Create classes to wrap calls to Java, dynamically or otherwise.
Clojure's access to Java is either via reflection, or, with type
inference, direct. No wrappers!
- Dynamically create classes as an optimization technique. Some
languages have dynamic OO strategies that were predicated on
interpretation. When trying to make them run fast on the JVM, you want
to compile to bytecode the results of that strategy, often based on
dynamic data, at runtime. And on the JVM, bytecode means classes.
Because the runtime profile or class/method hierarchy might change,
these optimizations sometimes need to be thrown away and recalculated,
thus potentially accumulating garbage in any class-related area the
JVM doesn't clean up. I expect the collectibility of classes will
improve in future VMs.
On a long-running Clojure web app you'd just need to take care not to
reload anything that didn't need reloading, but loading fixed fns
should not present a permgen problem. In any case, you know what's
going on, a fn definition creates a class, no other hidden class gen.
Note also that by fn definition I mean the occurrence in code, not the
execution:
(defn foo [x] (fn [] x))
creates two classes, no matter how many times foo is called. Each call
to foo creates an instance of the same class.
One nice thing about Clojure is it was written to run well on today's
(actually yesterday's) JVM. JVM enhancements will be nice, but we're
not waiting for nor dependent upon them.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
