Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JRuby 9000 released

blog.jruby.org

Post reply on HN
Print view View original

71–80 of 119 posts

Re: JRuby 9000 released

#71

Post by headius »

aurochs wrote: post #11
gary4gar wrote: post #5

is it faster than MRI?

It should be faster. I haven't seen any newish real world benchmarks to that effect though. These web benchmarks give some conflicting results between MRI and JRuby : https://www.techempower.com/benchmarks/#section=data-r10&hw=... .

They're a mixed bag because they're benchmarking libraries more than they're benchmarking runtimes. Often the JRuby-specific versions of libraries (e.g. activerecord-jdbc) do not get the same performance attention as the ones for MRI, and as a result they perform worse.

I know this is small consolation, but everything in the JRuby ecosystem is continuing to improve every day. When there's specific reproducible cases where we're slower, we take them very seriously.

Re: JRuby 9000 released

#72

Post by headius »

juliangregorian wrote: post #31
gary4gar wrote: post #5

is it faster than MRI?

If you need system-level bindings: no. If you use threading: yes.

What do you mean? JRuby can make system calls as fast as MRI, generally. We don't support their C extension API, but we support and maintain an FFI library to programmatically call C from Ruby.

Re: JRuby 9000 released

#73

Post by headius »

rurounijones wrote: post #55
pesnk wrote: post #8

Earlier quoted context omitted.

Course it is. JRuby has been faster then MRI for a long time. That does not mean I use it for production.

True in the 1.8 1.9 era. Against 2.2 it is not an automatic "Is faster"

Ruby performance has not improved substantially since 2.0, and we should almost always be faster for straight-line workloads. If we're not...tell me.

Re: JRuby 9000 released

#74

Post by headius »

joegyoung wrote: post #7

If I committed to using jRuby instead of regular ruby, I would have that nagging fear that Oracle would go after all the other companies that build their product using Java APIs.

We work closely with engineers at Oracle and JRuby is one of the premier projects on the JVM. There's also no legal way they could come after us; their suit against Google is about copying Java APIs, a very narrow domain.

Re: JRuby 9000 released

#75

Post by incepted »

Freaky wrote: post #27

Concurrent threads using magic regexp vars like $1 stomp all over each other, quite nasty: https://github.com/jruby/jruby/issues/3031 Stumbling over a serious race condition in the first 5 minutes of trying it with real code makes me a bit wary. All the performance in the world isn't much good if it's randomly wrong :/

I can make my code arbitrarily fast if it doesn't have to be correct.

Re: JRuby 9000 released

#76

Post by Freaky »

headius wrote: post #60
Freaky wrote: post #27

Concurrent threads using magic regexp vars like $1 stomp all over each other, quite nasty: https://github.com/jruby/jruby/issues/3031 Stumbling over a serious race condition in the first 5 minutes of trying it with real code makes me a bit wary. All the performance in the world isn't much good if it's randomly wrong :/

This is not a hard one to fix but it didn't make the final release and had never been reported before, despite being largely the same for 9 years. It will be fixed as soon as we can get to it. I will echo what others have said, though...closures capture and share a lot of other state. $~ and the related vars like $1 are supposed to be "special" but there's other state you're going to stomp on all Ruby impls. It's bet…

> had never been reported before, despite being largely the same for 9 years

I'll admit to encountering weird "er, why is that randomly nil" errors quite regularly with JRuby when load testing webservers, which, er, I've never reported. It's never been obvious where the fault was, really. And it always seemed unlikely to be your fault, tsk ;)

> It's better to avoid using closure state if you know it's going to be called across threads

Yeah. In this case it was a hash of name -> lambda pairs which boiled down to variations on:

    ->(obj) do
      case obj.bla
        when /foo(.*)/ then "FOO_#{$1.upcase}"
        when /bla(.*)/ then $1
      end
    end
Called in lots of tight loops from a pool of worker threads. I refactored it into something neater, but it still should have worked fine :)

Re: JRuby 9000 released

#77

Post by headius »

Freaky wrote: post #76
headius wrote: post #60

Earlier quoted context omitted.

This is not a hard one to fix but it didn't make the final release and had never been reported before, despite being largely the same for 9 years. It will be fixed as soon as we can get to it. I will echo what others have said, though...closures capture and share a lot of other state. $~ and the related vars like $1 are supposed to be "special" but there's other state you're going to stomp on all Ruby impls. It's bet…

> had never been reported before, despite being largely the same for 9 years I'll admit to encountering weird "er, why is that randomly nil" errors quite regularly with JRuby when load testing webservers, which, er, I've never reported. It's never been obvious where the fault was, really. And it always seemed unlikely to be your fault, tsk ;) > It's better to avoid using closure state if you know it's going to be cal…

It would be worth proposing to ruby-core that captured closures are thread-local, but that would break a lot of code that actually depends on the sharing. Programming is hard :-(

Re: JRuby 9000 released

#78

Post by headius »

Confusion wrote: post #50
Freaky wrote: post #46

Earlier quoted context omitted.

The same bug still exists in JRuby 9000, and was in fact the first thing I ran into when trying it. Considering threading is the main selling point, one of the commonest patterns of regexp use being completely and dangerously broken with them would have seemed like something of a showstopper.

Ah, I didn't get that from your original post. So JRuby 9000 shipped with a known concurrency bug that, from the face of it, seems likely to be a problem in actual use. I agree that seems a bit worrying.

You have to ship some time. Noisy bugs get fixed...and patches are always accepted :-)

Re: JRuby 9000 released

#79

Post by jshen »

headius wrote: post #63
jshen wrote: post #57

Earlier quoted context omitted.

Have you tried the pure-Java fallback on App Engine? I tried it for JRuby 1.7 and it didn't work. I haven't tried yet with 9000, have you?

We welcome GAE users of JRuby but they never seemed to be a big segment of the community. And we continue to maintain non-native IO and process logic for limited environments. If that is not sufficient for GAE, we'll work with you to make it so.

Jruby 1.7 simply doesn't work in GAE, and maybe it's not worth making it work there, which I would understand. I opened an issue a while ago (https://github.com/jruby/jruby/issues/2304) and I spent about a week trying to fix it. Each time I fixed one issue another one popped up and I gave up after hacking up JRuby beyond my comfort level.

Edit: I just want to stress, the JRuby team is amazing, and I've always been impressed with the responsiveness and openness of the team. This comment isn't meant as a critique in anyway, just a statement of fact with my experience trying to run JRuby on app engine.

Re: JRuby 9000 released

#80

Post by jrochkind1 »

headius wrote: post #60
Freaky wrote: post #27

Concurrent threads using magic regexp vars like $1 stomp all over each other, quite nasty: https://github.com/jruby/jruby/issues/3031 Stumbling over a serious race condition in the first 5 minutes of trying it with real code makes me a bit wary. All the performance in the world isn't much good if it's randomly wrong :/

This is not a hard one to fix but it didn't make the final release and had never been reported before, despite being largely the same for 9 years. It will be fixed as soon as we can get to it. I will echo what others have said, though...closures capture and share a lot of other state. $~ and the related vars like $1 are supposed to be "special" but there's other state you're going to stomp on all Ruby impls. It's bet…

Huh, if the local various was only scoped to the closure block, and not above it, I would never expect it to be shared. I would think "avoid using closure state" means exactly that, use only local variables scoped no higher than the closure block itself. (It's true this can sometimes be difficult to ensure in ruby; block local variables can help).

Do I understand things right, or am I wrong here?

I guess the question is where the regexp special vars are scoped to though, I see how that's not entirely clear.

Post reply on HN