On Sunday 14 September 2008 05:57, Rich Hickey wrote: > 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.ht > >ml > > > > Nutter mentions a possible OutOfMemory condition that can occur due > > to filling the PermGen part of the heap with class information, ...
I've had similar questions, though I haven't yet read Charles' article. > 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. What is the magnitude of the space overhead of a class' internal representation, beyond the bytecodes comprising its method(s)? > More to the permgen point, Clojure does not do any dynamic ephemeral > class creation. It creates classes for the functions you define. > Period. > > ... > > 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. Why is an instance creation required for an invocation? I thought you used the JVM stack for calling and parameter passing both for Clojure functions and (naturally) for calls to "ordinary" Java methods. If each invocation of a Clojure function requires instantiation of the function's class, aren't you effectively using those instances as call stack frames? And does this not limit function call rate to significantly less than the object allocation rate? And doesn't it rapidly tear through the eden space? If it isn't obvious, I know very little about the JVM or about how you compile Clojure to JVM bytecodes, so perhaps I'm way off. Please excuse my ignorance. > 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. I've also been wondering whether there's anything coming in the JVM that will relax the current TCO limitations in Clojure? > Rich Randall Schulz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
