PlanetJava
Custom Search

java-vm-languages
[Top] [All Lists]

Re: Re: new milestone build for Renjin - R for the JVM

Subject: Re: Re: new milestone build for Renjin - R for the JVM
Date: Tue, 17 May 2011 11:40:25 -0400
That is all an optimization that can come a *lot* later, though, and
should only be adopted after proving they are actually gains. Start
simple. The perfect is the enemy of the good.
By the time you get to that point, Java 7 will be out with
MethodHandles and invokedynamic, and you'll really, *really* want to
look into them over and against any kind of reflection hackery, no
matter how optimized.
~~ Robert.
On Tue, May 17, 2011 at 11:02 AM, John Cowan 
<[email protected]> wrote:
> On Tue, May 17, 2011 at 9:15 AM, Alexander Bertram
> <[email protected]> wrote:
>
>> 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 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
>> method?
>
> FWIU, the optimal approach if you are batch-compiling is to stuff N
> functions into a single class as static methods using this sort of
> framework:
>
> public class FooBarBaz {
>  private int _function;
>  private FooBarBaz(function) { _function = function; }
>  public static final fooFunction = new FooBarBaz(0);
>  public static final barFunction = new FooBarBaz(1);
>  public static final bazFunction = new FooBarBaz(2);
>  private static Object foo(Object arg) { ... }
>  private static Object bar(Object arg) { ... }
>  private static Object baz(Object arg) { ... }
>  public Object apply(Object arg) {
>    switch (_function) {
>    case 0: return fooFunction(arg);
>    case 1: return barFunction(arg);
>    case 2: return bazFunction(arg);
>  }
> }
>
> Note that all functions in a given class need to have the same
> Java-level type signature. You can avoid this by using Object[]s, but
> that's additional overhead.
>
> This approach lets you run with no reflection overhead, and hopefully
> the static methods will be inlined by the JIT (if not, you can inline
> them yourself).  You also reduce the number of classes by a
> (potentially large) linear factor, which holds down on permgen
> consumption.
>
> --
> GMail doesn't have rotating .sigs, but you can see mine at
> http://www.ccil.org/~cowan/signatures
>
> --
> You received this message because you are subscribed to the Google Groups 
> "JVM Languages" group.
> To post to this group, send email to 
> jvm-languages-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
> To unsubscribe from this group, send email to 
> [email protected]
> For more options, visit this group at 
> http://groups.google.com/group/jvm-languages?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups "JVM 
Languages" group.
To post to this group, send email to 
jvm-languages-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jvm-languages?hl=en.
msgmiddle
<Prev in Thread] Current Thread [Next in Thread>
Current Sitemap | © 2012 planetjava | Contact | Privacy Policy