

JRuby 1.7.0. Released - sheff
http://www.jruby.org/2012/10/22/jruby-1-7-0.html

======
ZitchDog
> InvokeDynamic support

This is the big one, in my opinion. See here[1] for some benchmarks of JRuby +
invokedynamic. We're talking orders of magnitude for some benchmarks.

[1] [http://blog.headius.com/2011/08/invokedynamic-in-jruby-
const...](http://blog.headius.com/2011/08/invokedynamic-in-jruby-constant-
lookup.html)

~~~
igouy
_some benchmarks_ from Wed, 10 Oct 2012

jruby-1.7.0.RC2 -Xcompile.invokedynamic=true

<http://shootout.alioth.debian.org/u32/jruby.php>

~~~
ksec
So with about the same CPU time, JRuby will use up to 100x memory in worst
case?

Anyway Ruby 2.0 is suppose to solve the Ruby is Slow problem. although i have
yet to see any evidence that will the case. Sigh.

~~~
bascule
> So with about the same CPU time, JRuby will use up to 100x memory in worst
> case?

The JVM often trades increased memory usage for increased performance. That
said "100x memory" is total hyperbole, even in the context of a
microbenchmark. If you want the JVM to use less RAM, you can turn down the
maximum heap size. Otherwise the heap will grow until it reaches close to full
before the GC does a stop-the-world style collection of the old generation.

> Anyway Ruby 2.0 is suppose to solve the Ruby is Slow problem

Absolutely not. There are presently no plans to add a JIT compiler to the de
facto Ruby interpreter.

The JVM on the other hand has the most advanced JIT compiler in the world.
InvokeDynamic on Java 7 allows JRuby to do method inlining, and on Java 8 it
will be able to take advantage of the full suite of HotSpot optimizations,
including escape analysis and lock elision when compiling Ruby code into
machine code.

No other Ruby VM will have that level of optimization.

~~~
mbell
> Otherwise the heap will grow until it reaches close to full before the GC
> does a stop-the-world style collection of the old generation.

Most real applications will be using ConcMarkSweepGC(or G1) and ParNewGC. With
these collectors the JVM won't just burn through all the memory and halt the
world unless you throw a workload at it which the GC can't handle with its
normal GC cycles.

The GC makes small sweeps regularly but the duration of those sweeps is
limited to ensure relatively consistent response time. If you were creating
and throwing away so many objects which were promoted to the tenured
generation that these small, time limited, GC sweeps couldn't keep up, then
you would see the heap grow to its maximum and a 'stop the world' GC would
take place. In practice that doesn't happen in the vast majority of workloads.

~~~
bascule
No, you're wrong, an _extremely_ scant number of applications can completely
avoid allocating memory in the old generation. Your best bet would probably be
to use the Disruptor approach of preallocating everything then avoiding any
subsequent allocations if that's really what you want to accomplish. However,
if you honestly believe "most real world applications" can avoid allocating
memory in the old generation, I'd sure love to see some graphs of some heap
profiles of real world usage of these applications!

CMS does a stop the world collection of the old generation, however it will do
an incremental collection of the eden generation. If you've ever looked at a
graph of the JVM heap observing CMS running under VisualVM or YourKit, you'll
notice a distinct sawtooth pattern to its collections. The diagonal parts of
the sawtooth represent incremental collections in eden space. The vertical
parts of the sawtooth represent stop-the-world collections of the old
generation.

The "small regular sweeps" you're talking about affect the eden generation,
not the old generation. Collecting the old generation is a stop the world
operation in every JVM GC option except Azul's C4 collector. C4 resorts to all
sorts of clever tricks to avoid stopping the world, most notably read barriers
and eager pointer updates. On the Azul hardware, these tricks involved
hardware transactional memory. On x86 they don't have HTM (at least until
Transactional Synchronization Extensions ship on Haswell). What they do,
however, is quickly set up GC invariants and a trap on a given page. Whatever
thread accesses a page that contains an object which needs to be relocated
relocates the object on the GC's behalf and gets the new pointer. All that
said, C4 is only available on the Azul JVM, which is commercial.

CMS can't do this. It stops the world at a JVM safe point whenever it needs to
collect the old generation.

~~~
mbell
CMS collector has two different types of collections it will do on the old
generation. Both are "stop the world" but for drastically different amounts of
time. During its 'normal' operation most of the sweep is done concurrently
with two short "stop the world" points for each GC cycle. If it can't keep up,
then it will do a full blow "stop the world for real" collection.

------
joevandyk
Biggest things stopping me from using jruby:

1\. Incomplete integration with postgresql. The ActiveRecord jdbc adapater
doesn't have all the features that the standard pg adapter does.

2\. Slow startup / test runs. At one point, loading large amounts of files
(like during rails bootup) was much slower on jruby than MRI.

~~~
headius
Based on this comment, I started looking into JRuby support for the pg gem. I
think it's possible; I have started stubbing it out, and the Postgresl JDBC
driver publishes additional interfaces that provide everything folks here have
been asking for.

I'm looking for help filling it out. Here's the mostly stubbed extension:

<https://github.com/headius/jruby-pg>

And here's the docs for pgsql's hidden interfaces (cast the JDBC objects to
these, and you're good to go):

[http://jdbc.postgresql.org/documentation/publicapi/index.htm...](http://jdbc.postgresql.org/documentation/publicapi/index.html)

~~~
sheff
This would be brilliant, as Postgres is one of the most commonly used
databases with Rails (generally, and also because of Heroku) so having feature
parity between the pg gem and JDBC drivers that you can use with, for example,
Torquebox would be great, especially for people wanting to migrate to JRuby.

I did some basic benchmarking with one of the JRuby 1.7 preview releases and
was impressed enough with the speed benefits to want to try it out with a
small app on Torquebox when JRuby 1.7 was released.

Thanks to joevandyk and xiljin for pointing out the search_path and datatype
support situation before I undoubtedly encountered them myself - and love the
fact that headius has immediately leapt in to try and fix things :-)

------
mberning
JRuby is really great. I use it every day for both work and personal projects.

Big thanks to all the contributors!

------
sheff
Looking forward to installing it and trying it out with Torquebox (
<http://torquebox.org/> ) for a new project.

------
lloeki
Not only does it default to 1.9 after one year, it catches up all the way to
1.9.3-p286, released only ten days ago.

------
VeejayRampay
Congratulations to all devs, committers, documentation maintainers,
supporters, donators, secret lovers and overall alternative ruby enthusiasts.

------
josephlord
Is JRuby worth using if JVM language integration isn't needed? E.g. A fairly
standard Rails app.

~~~
threedaymonk
My experience is that if you don't need JRuby (for Java interop or to satisfy
pointy-haired strictures), you probably won't see much benefit from choosing
it, at least for a Rails app.

On one hand, JRuby is technically a much better Ruby than Ruby, and if you
want to improve bulk throughput you'll probably benefit. On the other, if bulk
throughput were important, Ruby probably wouldn't be your first choice, and
there are some downsides.

The biggest problem, especially for Rails, is the warm-up cost. Rails's start-
up time is already painful, and adding to that hardly improves the test-
develop cycle. I've not tested this latest release, but in 1.6.8, running a
test suite was multiples slower than C Ruby. Test suites, which run a lot of
different code, aren't really representative of real-world workloads, but if
you're working on an application it really hurts.

You might also have trouble with gems that have compiled extensions. It takes
a bit of Gemfile fiddling, but there are alternatives to most of those.

For applications other than Rails (which is really a bit of a pathological
case), JRuby seems well worth a look. I've never found C Ruby's threading up
to the job of making a responsive GUI application, but JRuby might work a lot
better with its JVM-backed threads.

------
mark_l_watson
cool. "rvm install jruby-1.7.0" works :-)

~~~
jamesbritt
I initially got an "Error: Your application used more stack memory than the
safety cap" message running that.

This solved it: <https://github.com/jruby/jruby/issues/346>

tl;dr:

    
    
        rvm get stable
    

then reinstall jruby 1.7.0

------
mseepgood
Best Ruby implementation so far.

