On Sep 14, 10:09 am, Randall R Schulz <[EMAIL PROTECTED]> wrote:
> 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)?
>
I have no idea. That's a JVM implementation issue, the answer to which
is likely to change from JVM to JVM.
> > 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?
It's not. This function, foo, returns a closure. It is the closure for
which an instance is created.
> I thought you
> used the JVM stack for calling and parameter passing both for Clojure
> functions and (naturally) for calls to "ordinary" Java methods.
I do.
> If each
> invocation of a Clojure function requires instantiation of the
> function's class
It doesn't.
> > 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?
TCO is on the list of JVM enhancements being considered. I'm not sure
it has high priority, though.
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
-~----------~----~----~----~------~----~------~--~---
