Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: JRuby 1.7.0.pre1
    • Component/s: None
    • Labels:
      None
    • Environment:
      jruby 1.7.0.dev (ruby-1.8.7-p330) (2011-11-16 b7c3cc2) (Java HotSpot(TM) Client VM 1.6.0_24) [Windows 7-x86-java]
    • Testcase included:
      yes
    • Number of attachments :
      0

      Description

      Thread.new { loop { `ls` } }
      
      gets
      

      causes
      Exception in thread "RubyThread-0: bad.rb:1" java.lang.OutOfMemoryError: unable to create new native thread
      ...

      Replacing "gets" with "sleep" and it works fine. MRI seems to work fine both ways.

      (Linux and Windows)

        Activity

        Hide
        Hiro Asari added a comment -

        I confirmed the problem (again?). This might be a known limitation on JVM.

        See the comment here: https://github.com/jruby/jruby/blob/d2c6bed6247fb981de4615cada83a296de9c88c8/src/org/jruby/util/ShellLauncher.java#L1324-1333

        Suggestions are welcome.

        Show
        Hiro Asari added a comment - I confirmed the problem (again?). This might be a known limitation on JVM. See the comment here: https://github.com/jruby/jruby/blob/d2c6bed6247fb981de4615cada83a296de9c88c8/src/org/jruby/util/ShellLauncher.java#L1324-1333 Suggestions are welcome.
        Hide
        Roger Pack added a comment -

        in those lines I don't quickly see thread creation--where are the extra threads coming from I wonder?

        Show
        Roger Pack added a comment - in those lines I don't quickly see thread creation--where are the extra threads coming from I wonder?
        Hide
        Hiro Asari added a comment -

        We are creating a new thread for each call to `ls`.

        Show
        Hiro Asari added a comment - We are creating a new thread for each call to `ls` .
        Hide
        Charles Oliver Nutter added a comment -

        Hmmm...we do have a thread pool we could use for this. I'm going to give that a try.

        Show
        Charles Oliver Nutter added a comment - Hmmm...we do have a thread pool we could use for this. I'm going to give that a try.
        Hide
        Charles Oliver Nutter added a comment -

        I've pushed a fix to a temporary post_1.7_pre1 branch in 4f0b781. My fix is unconventional, but I'm surprisingly comfortable with it.

        commit df125bee433ea3fd2452926ef3c5d1ece5d5d9b6
        Author: Charles Oliver Nutter <headius@headius.com>
        Date:   Thu May 17 19:15:57 2012 -0500
        
            Fix JRUBY-6248
            
            I'm committing a cardinal sin here by using Thread#stop, but I
            think in this case it's warranted (and probably safe enough). The
            threads in question are doing nothing but spinning on two IO
            streams, and even if they leave those streams unusable we're
            walking away from them anyway.
            
            This fix makes thread count stay stable for a tight backquote loop
            as described in the bug.
            
            I did try using our Executor, but the problem isn't reusing
            threads, it's terminating them completely.
        
        Show
        Charles Oliver Nutter added a comment - I've pushed a fix to a temporary post_1.7_pre1 branch in 4f0b781. My fix is unconventional, but I'm surprisingly comfortable with it. commit df125bee433ea3fd2452926ef3c5d1ece5d5d9b6 Author: Charles Oliver Nutter <headius@headius.com> Date: Thu May 17 19:15:57 2012 -0500 Fix JRUBY-6248 I'm committing a cardinal sin here by using Thread#stop, but I think in this case it's warranted (and probably safe enough). The threads in question are doing nothing but spinning on two IO streams, and even if they leave those streams unusable we're walking away from them anyway. This fix makes thread count stay stable for a tight backquote loop as described in the bug. I did try using our Executor, but the problem isn't reusing threads, it's terminating them completely.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Roger Pack
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: