JRuby

Memory leak in closure coercion

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: