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

51–60 of 119 posts

Re: JRuby 9000 released

#51

Post by dragonwriter »

Freaky wrote: post #46
Confusion wrote: post #38

Earlier quoted context omitted.

Your comment has little to do with JRuby 9000, as the bug reported there was observed in JRuby 1.7.20. Yes, JRuby has bugs, like MRI, like any interpreter or compiler.

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.

> one of the commonest patterns of regexp use

Is it really? Even fairly early in the Ruby 1.8.x era, most recommendations I saw were that the magic regexp globals (and many other magic globals) were a perlism that should generally be avoided.

Re: JRuby 9000 released

#52

Post by cheald »

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.

Well, it's fair to say "it works in MRI"; $1 being frame-local and thread-local is an exception to the rule, but it is How It Works. JRuby should behave similarly, full stop.

Re: JRuby 9000 released

#53

Post by rurounijones »

ch4s3 wrote: post #45
chaostheory wrote: post #36

Earlier quoted context omitted.

For things like Rails, that are going to be running all the time, does the JVM warm up time really matter?

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.

Re: JRuby 9000 released

#54

Post by infraruby »

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.

$~ and friends are not global:

  def f
    p $~ # => nil
    "123" =~ /\w+/
    p $~ # => #
  end

  p $~ # => nil
  "abc" =~ /\w+/
  p $~ # => #

  f

  p $~ # => #

Re: JRuby 9000 released

#56

Post by rugmug5 »

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.

You're using the standard jvm, why would they care?

Re: JRuby 9000 released

#57

Post by jshen »

chrisseaton wrote: post #42
mdavidn wrote: post #39

Earlier quoted context omitted.

This will prevent running JRuby 9000 in (today's) Google App Engine. The project has been drifting away from App Engine support for some time now. See #2304. https://github.com/jruby/jruby/issues/2304

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?

Re: JRuby 9000 released

#58

Post by divideby0 »

chrisseaton wrote: post #10
Scarbutt wrote: post #2

JRuby 9000 now uses native operations for much of IO and almost all of Process. This makes us the first POSIX-friendly JVM language. Did they achieved this via JNI?

The system is called JNR - Java Native Runtime - http://www.oracle.com/technetwork/java/jvmls2013nutter-20135... . It uses libffi, which I guess the final call is made to via JNI.

Charlie Nutter gave a great talk covering this and a lot of additional new JVM features here:

https://vimeo.com/114187541

Edit: The JNR stuff is covered around 42 minutes in.

Re: JRuby 9000 released

#60

Post by headius »

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 better to avoid using closure state if you know it's going to be called across threads, because most of that state will be shared on all Rubies.

Post reply on HN