Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: JRuby 1.1.4
    • Fix Version/s: JRuby 1.1.4
    • Component/s: None
    • Labels:
      None
    • Environment:
      Fedora Linux 9, Sun Java 1.6.0_06, JRuby trunk 7520
    • Number of attachments :
      0

      Description

      Same application as in JRUBY-2803.

      When run with JRuby 1.1.3 with JIT disabled the application heap size peaks at 26MB, and then reduces and stabilizes at 13MB. NICE!

      When run with JRuby trunk (7520), JIT disabled or enabled, the application heap size never stops growing and an OutOfMemoryError occurs after a while.

      Maybe I'm doing something wrong, bit since it worked on 1.1.3 I suspect the recent changes have triggered this.

      I'm new to RSpec. How would I write a spec for this?

        Activity

        Hide
        Charles Oliver Nutter added a comment -

        Can't ship with a potential leak. Marking as blocker.

        Show
        Charles Oliver Nutter added a comment - Can't ship with a potential leak. Marking as blocker.
        Hide
        Charles Oliver Nutter added a comment -

        I've confirmed this is a leak, probably a leak of classes created for closure coercion (and I updated the subject). I'm looking into it now.

        A trivial case to reproduce it:

        ➔ jruby -w --server -J-Xmx32M -rjava -e "while true; java.lang.Thread.set_default_uncaught_exception_handler { }; end"
        Error: Your application used more memory than the safety cap of 32M.
        Specify -J-Xmx####m to increase it (#### = cap size in MB).
        Exception trace follows:
        java.lang.OutOfMemoryError: Java heap space
        	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99)
        	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393)
        	at java.lang.StringBuilder.append(StringBuilder.java:120)
        	at org.jruby.util.CodegenUtils.sig(CodegenUtils.java:102)
        

        With a larger size:

        ➔ jruby -w --server -J-Xmx128M -rjava -e "while true; java.lang.Thread.set_default_uncaught_exception_handler { }; end"
        org.jruby.Main:100:in `run': java.lang.OutOfMemoryError: PermGen space
        	from org.jruby.Main:84:in `main'
        

        Uwe confirmed that replacing the closure conversion with a concrete class makes the memory issues go away.

        Show
        Charles Oliver Nutter added a comment - I've confirmed this is a leak, probably a leak of classes created for closure coercion (and I updated the subject). I'm looking into it now. A trivial case to reproduce it: ➔ jruby -w --server -J-Xmx32M -rjava -e "while true; java.lang.Thread.set_default_uncaught_exception_handler { }; end" Error: Your application used more memory than the safety cap of 32M. Specify -J-Xmx####m to increase it (#### = cap size in MB). Exception trace follows: java.lang.OutOfMemoryError: Java heap space at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:99) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:393) at java.lang.StringBuilder.append(StringBuilder.java:120) at org.jruby.util.CodegenUtils.sig(CodegenUtils.java:102) With a larger size: ➔ jruby -w --server -J-Xmx128M -rjava -e "while true; java.lang.Thread.set_default_uncaught_exception_handler { }; end" org.jruby.Main:100:in `run': java.lang.OutOfMemoryError: PermGen space from org.jruby.Main:84:in `main' Uwe confirmed that replacing the closure conversion with a concrete class makes the memory issues go away.
        Hide
        Uwe Kubosch added a comment -

        Got a patch from headius, and now the heap size never exceeds 6MB.

        NICE!

        Show
        Uwe Kubosch added a comment - Got a patch from headius, and now the heap size never exceeds 6MB. NICE!
        Hide
        Charles Oliver Nutter added a comment -

        This should be fixed in r7523. I modified the interface impl generation to take into account both the metaclass hashcode and the interface hashcodes, and to ignore singleton classes when the "real class" is proc, which would indicate a closure-conversion is in progress. This eliminates the leak and improves the performance of closure conversion by almost 10x over previous and a good 3x over the fastest conversions in 1.1.3 (which required -X-C...the current logic is now 100x faster than 1.1.3 in JIT mode).

        Show
        Charles Oliver Nutter added a comment - This should be fixed in r7523. I modified the interface impl generation to take into account both the metaclass hashcode and the interface hashcodes, and to ignore singleton classes when the "real class" is proc, which would indicate a closure-conversion is in progress. This eliminates the leak and improves the performance of closure conversion by almost 10x over previous and a good 3x over the fastest conversions in 1.1.3 (which required -X-C...the current logic is now 100x faster than 1.1.3 in JIT mode).

          People

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

            Dates

            • Created:
              Updated:
              Resolved: