buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spiewak <>
Subject Re: JRuby AOT Compilation for All-in-One
Date Wed, 07 Apr 2010 20:19:38 GMT
Actually, according to Charles Nutter, this probably isn't the best idea.
Apparently AOT compilation is mostly just good for obfuscation, it doesn't
improve performance much (if at all).  In fact, it actually hurts startup
performance because there's more bytecode to verify.  So, let's not go down
that road...  :-)

Instead of AOT compilation, what we could look into is bundler (  This will allow us to create a static
bundle which directly references all of the gems we need without actually
loading rubygems.  This would be hugely advantageous in terms of startup
performance, and could bring us to within spitting distance of Buildr on
MRI.  Unfortunately, it would also mean that gem dependencies and Buildr
plugins packaged as gems would not work with the all-in-one distribution.
Is this a worthwhile tradeoff?  I imagine most people who would go for the
all-in-one are not going to be interested in gem-based dependencies for
precisely the same reasons.


On Wed, Apr 7, 2010 at 1:39 PM, Antoine Toulme <>wrote:

> This would represent a huge performance gain for Buildr! Thanks for putting
> it together.
> Antoine
> On Wed, Apr 7, 2010 at 11:23, Daniel Spiewak <> wrote:
> >
> >
> > This is a patch to run the JRuby ahead-of-time compiler against the
> > *entire*Ruby distribution and installed gems prior to zipping for
> > distribution.  The
> > motivations behind this are two-fold.  First, the resulting .class files
> > are
> > substantially smaller than the original .rb files and so the size of the
> > distributable goes down.  More importantly though, AOT compilation
> imparts
> > a
> > significant performance advantage, particularly when we can apply some
> > optimizations.  Unfortunately, documentation seems to be limited (read:
> > non-existant) where it comes to tuning the AOT compiler, so I had to just
> > guess based on what I know of its architecture.  The settings I am using
> > are
> > the same ones I've been using with the regular JRuby JIT running Buildr
> for
> > more than six months, so I think they're fairly safe (and they do yield
> > substantial benefits).
> >
> > The big problem I'm having is that the compiler always seems to return an
> > error.  It does compile everything (except for our buildr/java/bdd.rb and
> > one of Hoe's files, which cause internal exceptions), and it doesn't
> print
> > any errors, but regardless of what I do, the result always seems to be an
> > error code of 1.  Headius, if you're listening in lurk mode, we could use
> > some help here.  :-)
> >
> > Hopefully this change will help streamline our all-in-one distribution
> and
> > maybe make it a compelling option even for those who are comfortable with
> > `gem install`.
> >
> > Daniel
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message