JRuby AOT Compilation for All-in-One

[Daniel Spiewak <dj...@gmail.com>]

http://paste.pocoo.org/show/198856/

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

Re: JRuby AOT Compilation for All-in-One

[Antoine Toulme <an...@lunar-ocean.com>]

On Wed, Apr 7, 2010 at 11:23, Daniel Spiewak <dj...@gmail.com> wrote:

> http://paste.pocoo.org/show/198856/
>
> 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
>

Re: JRuby AOT Compilation for All-in-One

[Charles Oliver Nutter <he...@headius.com>]

On Wed, Apr 7, 2010 at 4:12 PM, Antoine Toulme <an...@lunar-ocean.com> wrote:
> Can we add a gem to the "bundle" after the fact ?
> If that's possible, I'd give two ways for people to load buildr4osgi:
> -in a hurry: use rubygems
> -with time: place in folder.

I believe so, assuming obviously that you haven't stuffed the bundle
into a jar file. If you're shipping app + bundle as a zip that gets
expanded, it's not hard to re-bundle additional items in (or just fall
back on RubyGems).

At any rate, there's a whole set of options for providing a
neatly-packaged Buildr+JRuby anyone can use with just a JVM available.

- Charlie

Re: JRuby AOT Compilation for All-in-One

[Antoine Toulme <an...@lunar-ocean.com>]

On Wed, Apr 7, 2010 at 14:07, Charles Oliver Nutter <he...@headius.com>wrote:

> On Wed, Apr 7, 2010 at 3:42 PM, Antoine Toulme <an...@lunar-ocean.com>
> wrote:
> > For Buildr4OSGi, I would need to create my own distribution of Buildr
> that
> > includes the Buildr4OSGi gem. Before long, you'll get a mess. It's still
> a
> > valuable option imo.
>
> You can still *use* RubyGems if you want, but Bundler would allow you
> to only load if it you need to. "Typical" buildr usage wouldn't need
> to go outside the base distro.
>
Can we add a gem to the "bundle" after the fact ?
If that's possible, I'd give two ways for people to load buildr4osgi:
-in a hurry: use rubygems
-with time: place in folder.

>
> > I really thought AOT was helping. I think there was a way to build buildr
> as
> > an executable jar or something - oh well, I forgot.
>
> Precompiling is not a requirement for bundling everything into a
> single jar, other than that you need a "main" entry point that Java
> can see. You basically can just stuff all the .rb files into a jar and
> they'll work like they're on the filesystem (modulo crazy __FILE__
> path manipulation some people do).


> - Charlie
>

Re: JRuby AOT Compilation for All-in-One

[Charles Oliver Nutter <he...@headius.com>]

On Wed, Apr 7, 2010 at 3:42 PM, Antoine Toulme <an...@lunar-ocean.com> wrote:
> For Buildr4OSGi, I would need to create my own distribution of Buildr that
> includes the Buildr4OSGi gem. Before long, you'll get a mess. It's still a
> valuable option imo.

You can still *use* RubyGems if you want, but Bundler would allow you
to only load if it you need to. "Typical" buildr usage wouldn't need
to go outside the base distro.

> I really thought AOT was helping. I think there was a way to build buildr as
> an executable jar or something - oh well, I forgot.

Precompiling is not a requirement for bundling everything into a
single jar, other than that you need a "main" entry point that Java
can see. You basically can just stuff all the .rb files into a jar and
they'll work like they're on the filesystem (modulo crazy __FILE__
path manipulation some people do).

- Charlie

Re: JRuby AOT Compilation for All-in-One

[Antoine Toulme <an...@lunar-ocean.com>]

For Buildr4OSGi, I would need to create my own distribution of Buildr that
includes the Buildr4OSGi gem. Before long, you'll get a mess. It's still a
valuable option imo.

I really thought AOT was helping. I think there was a way to build buildr as
an executable jar or something - oh well, I forgot.

On Wed, Apr 7, 2010 at 13:32, Rhett Sutphin <rh...@detailedbalance.net>wrote:

> Hi,
>
>
> On Apr 7, 2010, at 3:19 PM, Daniel Spiewak wrote:
>
>  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 (
>> http://github.com/carlhuda/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.
>>
>
> Loading rubygems is what makes buildr on JRuby slow?  I thought it was JVM
> startup time.
>
>
>  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.
>>
>
> I disagree with this.  At least some of people who want to use the
> all-in-one will be people who have acquired a bunch of source code that says
> "you need buildr to build this."  If the all-in-one doesn't allow
> extensions, then the people who provide said source code will have to say
> "you need buildr to build this, but not the one that's easy to install.
>  Sorry."
>
> Buildr's whole architecture is oriented around its smooth extensibility.
>  That seems like something to promote, not something to reserve for the
> elite who don't choose the easiest install path.
>
> Rhett
>
>
>
>> Daniel
>>
>> On Wed, Apr 7, 2010 at 1:39 PM, Antoine Toulme <antoine@lunar-ocean.com
>> >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 <dj...@gmail.com>
>>> wrote:
>>>
>>>  http://paste.pocoo.org/show/198856/
>>>>
>>>> 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
>>>>
>>>>
>>>
>

Re: JRuby AOT Compilation for All-in-One

[Daniel Spiewak <dj...@gmail.com>]

> Instead of AOT compilation, what we could look into is bundler (
>> http://github.com/carlhuda/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.
>>
>
> Loading rubygems is what makes buildr on JRuby slow?  I thought it was JVM
> startup time.


If it were just JVM startup time, you would see Ant and Maven taking just as
long to get rolling, and that just doesn't happen.

According to the JRuby team, the far-and-away top sources of slow startup
performance are Rubygems and client vs server mode JVM (in that order).
Apparently in the JRuby trunk with the JVM in -client mode, jruby -e "puts
'a'" can run in less than half a second.  Compare that to the five-ish
seconds required to get run `buildr --help`.

The whole -client JVM thing is something we can solve easily with our
all-in-one distribution since we're already using a custom startup script.
We can also add some of the unsafe optimizations I've found to be sound for
Buildr, which also helps both startup and overall performance.  However,
neither of those address the largest source of startup performance woes:
Rubygems.


>
>  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.
>>
>
> I disagree with this.  At least some of people who want to use the
> all-in-one will be people who have acquired a bunch of source code that says
> "you need buildr to build this."  If the all-in-one doesn't allow
> extensions, then the people who provide said source code will have to say
> "you need buildr to build this, but not the one that's easy to install.
>  Sorry."
>

Extensions are fine, you just wouldn't be able to get them via Rubygems.  At
least, not if we do this naively.  We may be able to set things up so that
we only load Rubygems if we actually need it for a project-defined extension
or dependency.  Otherwise, if it's just vanilla Buildr, we can leave
Rubygems untouched.  This would in a sense be the best of both worlds: most
projects would get super fast Buildr startup time, while the ones that
really need Rubygems could still use it.  We might even see some performance
boost due to the fact that the JVM will be more warmed up by the time it
gets to the point where we would determine Rubygems as necessary.

Daniel

Re: JRuby AOT Compilation for All-in-One

[Rhett Sutphin <rh...@detailedbalance.net>]

Hi,

On Apr 7, 2010, at 3:19 PM, Daniel Spiewak wrote:

> 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 (
> http://github.com/carlhuda/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.

Loading rubygems is what makes buildr on JRuby slow?  I thought it was  
JVM startup time.

> 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.

I disagree with this.  At least some of people who want to use the all- 
in-one will be people who have acquired a bunch of source code that  
says "you need buildr to build this."  If the all-in-one doesn't allow  
extensions, then the people who provide said source code will have to  
say "you need buildr to build this, but not the one that's easy to  
install.  Sorry."

Buildr's whole architecture is oriented around its smooth  
extensibility.  That seems like something to promote, not something to  
reserve for the elite who don't choose the easiest install path.

Rhett

>
> Daniel
>
> On Wed, Apr 7, 2010 at 1:39 PM, Antoine Toulme <antoine@lunar-ocean.com 
> >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 <dj...@gmail.com>  
>> wrote:
>>
>>> http://paste.pocoo.org/show/198856/
>>>
>>> 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
>>>
>>

Re: JRuby AOT Compilation for All-in-One

[Daniel Spiewak <dj...@gmail.com>]

Note: by "gem dependencies" I mean at the project level.  Buildr's own gem
dependencies (like Antwrap) would be in the clear.

Daniel

On Wed, Apr 7, 2010 at 3:19 PM, Daniel Spiewak <dj...@gmail.com> wrote:

> 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 (
> http://github.com/carlhuda/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.
>
> Daniel
>
>
> On Wed, Apr 7, 2010 at 1:39 PM, Antoine Toulme <an...@lunar-ocean.com>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 <dj...@gmail.com> wrote:
>>
>> > http://paste.pocoo.org/show/198856/
>> >
>> > 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
>> >
>>
>
>

Re: JRuby AOT Compilation for All-in-One

[Daniel Spiewak <dj...@gmail.com>]

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 (
http://github.com/carlhuda/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.

Daniel

On Wed, Apr 7, 2010 at 1:39 PM, Antoine Toulme <an...@lunar-ocean.com>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 <dj...@gmail.com> wrote:
>
> > http://paste.pocoo.org/show/198856/
> >
> > 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
> >
>

Re: JRuby AOT Compilation for All-in-One

[Antoine Toulme <an...@lunar-ocean.com>]

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 <dj...@gmail.com> wrote:

> http://paste.pocoo.org/show/198856/
>
> 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
>