On Tue, May 17, 2011 at 3:15 PM, Alexander Bertram
<[email protected]> wrote:
> Great question!
> FYI, this is renjin's implementation of a Thunk or "Promise" as it's
> called in R. The only difference
> is that the context needs to be provided to access the variables that
> were in scope when the thunk was created.
> My question for the JVM-niks out there is how feasable is it create a
> new jvm class for each thunk or function value?
> When you write a function in scala or clojure, does this get compiled
> into a new, separate class?
I don't know about Scala, but I know that in ABCL it does get compiled
to a new class, and I think in Clojure it's the same.
> I know invokedynamic will solve a lot of these problems, but in
> targeting java 6, is it worth economizing on the number of class,
> using for example reflection to dispatch a function call to a static
It depends. Reflection impacts very negatively on runtime performance.
Having a great number of classes consumes more memory and makes
startup slower (if you're loading a lot of them at startup), but
should be otherwise ininfluent on performance (gurus, please correct
me if I'm wrong). So at compile-time it's generally better to generate
classes than to generate code that uses reflection. Generating new
classes on the fly at runtime, instead, is certainly slower than
reflectively calling a method, so it may make sense for one-off
functions that call pre-existing code to use reflection rather than
generate a new class that will be subsequently thrown away. However,
that seems to be a pretty narrow case that's not worth addressing -
but I don't know how functions are typically used in R, so I can't
really comment about that.
You received this message because you are subscribed to the Google Groups "JVM
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at