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 12:36:23 -0500
On Tue, May 17, 2011 at 9:39 AM, James Iry 
<[email protected]> wrote:
> I think all the compiled JVM languages currently create a new jvm class for
> each lambda expression (by which I also include the eta expansion typically
> used to turn a "regular" function into an function value) and allocate an
> object for each closure.  For a few function values it's not a big deal, but
> over a large progam with lots of HOFs it's not cheap.  It costs time to load
> the classes at startup and costs memory to hold the classes in memory (under
> the current Snoracle JVM it uses precious permgen space).  There's also some
> cost to allocate the function value objects, and cost to dispatch to them
> (especially when hotspot determines the call is megamorphic).
JRuby compiles a given Ruby script entirely into a single .class file.
It is, however, not really a "normal" Java class, since the methods it
contains are just the bodies of all methods and closures in the script
itself. They are eventually bound into the class hierarchy or tied to
live closure state by either reflection, generated stub classes (our
own form of MethodHandles), or by java.lang.invoke MethodHandles. So
there's no strict requirement that a method/function/closure body be
its own class, either on-disk or in memory.
> Reflective calls to static methods would make the startup costs a bit
> cheaper while making the runtime costs significantly heavier. Plus you'd
> have to deal with the case when a function value needs to capture parts of
> its environment - the environment would have to be bundled up in an object.
>  If you're avoiding creating classes then you'd likely have to put the
> environment in a dictionary (a hash table or similar), so that's even more
> runtime cost.
The startup cost of many classes can be blunted by loading into the
bootstrap classloader (tricky and dangerous if your compiler might
produce bad code) or to a lesser extent by avoiding reflective loads
of those classes (allowing a single bulk load+verification phase when
a group of them boot). Reflection can help at startup, but not to a
massive degree...in JRuby, when booting all our generated stubs for
core methods, switching to reflective access from generated stub
classes saves 1-2s (and saves only about 0.5s compared to stub classes
loaded without verification).
- Charlie
-- 
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