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

61–70 of 119 posts

Re: JRuby 9000 released

#61

Post by Freaky »

rugmug5 wrote: post #48
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 :/

You really shouldn't be relying on globals anyway. Using $1 etc. is a serious code smell. It shouldn't by definition be threadsafe in any event. The only way that would work would be if you rely on the threads not actually running at the same time as an implementation detail of the MRI.

They're what MRI calls "svars", or special variables. They're thread and scope-local, and regardless of your feelings towards them, they're still used all over the place, in old and new code alike.

Re: JRuby 9000 released

#62

Post by headius »

infraruby wrote: post #54
rugmug5 wrote: post #48

Earlier quoted context omitted.

You really shouldn't be relying on globals anyway. Using $1 etc. is a serious code smell. It shouldn't by definition be threadsafe in any event. The only way that would work would be if you rely on the threads not actually running at the same time as an implementation detail of the MRI.

$~ and friends are not global: def f p $~ # => nil "123" =~ /\w+/ p $~ # => # end p $~ # => nil "abc" =~ /\w+/ p $~ # => # f p $~ # => #

Matz himself has said he regrets putting these variables in the language, and some day they may disappear. We'll match behavior as much as possible, but they're a relic no matter how you slice it.

Re: JRuby 9000 released

#63

Post by headius »

jshen wrote: post #57
chrisseaton wrote: post #42

Earlier quoted context omitted.

There's a pure-Java fallback that has most of the same functionality. But if you wanted precise POSIX function calls you probably weren't running on App Engine anyway.

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.

Re: JRuby 9000 released

#64

Post by headius »

ghufran_syed wrote: post #40
fny wrote: post #24

Earlier quoted context omitted.

As far as I'm aware, the port of pg 0.17.1 is alive and well: https://github.com/headius/jruby-pg

Is there any guidance out there about when to use activerecord-jdbc-adapter vs this gem (for postgres)?

In general everything ActiveRecord does should be supported by JDBC. The pg port is for cases where you need features the JDBC driver does not support but the C driver does, like geocoding etc.

Re: JRuby 9000 released

#65

Post by headius »

ch4s3 wrote: post #44
juliangregorian wrote: post #29

Earlier quoted context omitted.

Currently, there's $1700 in store for whoever does support it: https://www.bountysource.com/issues/5831191-tasks-to-finish-...

Yep, I've put up money for it myself, and regularly be on twitter for other folks to do the same. I wish a big company that uses jRuby would step up and support the tools they use :/

Agreed.

Re: JRuby 9000 released

#66

Post by ch4s3 »

rurounijones wrote: post #53
ch4s3 wrote: post #45

Earlier quoted context omitted.

No, its just a drag to TDD with.

I and others have had success with MRI on dev and JVM in prod to get around this. Maybe not for everyone but as long as you know what you are doing it is viable I think.

That's what we do as well. It works well enough.

Re: JRuby 9000 released

#67

Post by gsnedders »

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.

What VM doesn't ship with bugs likely to be a problem in actual use, though?

Re: JRuby 9000 released

#68

Post by headius »

aurochs wrote: post #9

JRuby is a great idea. It has one pitfall which consistently stops me from using it though : poor support with newer releases of Rails, usually due to the Active Record stack not working well with the AR JDBC adapter. I know some work was being done on a JRuby version of the standard pg gem (without the need for JDBC) which would be fantastic if it was completed and working.

This is really an unfortunte side effect of every Rails AR adapter being a one-off piece of code. In JRuby, there's not much code different between the databases, but in Rails they're all completely different. That means we basically have to emulate N different codebases just to be compatible. If they settled on a common database layer, our job would be done. Write your congressman.

Re: JRuby 9000 released

#69

Post by headius »

FooBarWidget wrote: post #16
gary4gar wrote: post #5

is it faster than MRI?

That depends on what you mean by faster. For CPU-bound work, JRuby is almost always faster. The JVM is very good at optimizing. However, the best performance doesn't kick in until the JVM is sufficiently warmed up, which means JRuby shines mostly for long-running tasks. Warming up can take a few minutes, although some people tell me that I should warm up for half an hour (!). On the flip side, JRuby starts much more…

We've added a --dev flag to JRuby that attempts to turn on fast-starting flags in JRuby and the JVM to reduce startup time. It can be as much as twice as fast.

We continue to try to improve startup performance, and hopefully over the next year we can close the gap a bit more.

Re: JRuby 9000 released

#70

Post by headius »

dragonwriter wrote: post #12
gary4gar wrote: post #5

is it faster than MRI?

JRuby used to be much faster than MRI (definitely so when MRI 1.8 was current), but MRI has gotten better faster than JRuby, and IIRC, its now mostly a mixed bag based on workload, particular application design choices, etc.

That's generally not true. MRI's straight-line performance has not improved as fast as JRuby's, and if we're ever slower than MRI it's generally something we're doing wrong. When we're doing things right, performance can be anywhere from two to ten times faster than MRI.
Post reply on HN