Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JRuby 9.0.1.0 takes > 500 MB of RAM to install bundler #3358

Closed
vassilevsky opened this issue Sep 28, 2015 · 11 comments
Closed

JRuby 9.0.1.0 takes > 500 MB of RAM to install bundler #3358

vassilevsky opened this issue Sep 28, 2015 · 11 comments

Comments

@vassilevsky
Copy link

Hello :)

I think JRuby is too memory-hungry.

# uname -a
Linux [redacted] 2.6.32-573.3.1.el6.x86_64 #1 SMP Thu Aug 13 22:55:16 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

# java -version
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

# ruby -v
jruby 9.0.1.0 (2.2.2) 2015-09-02 583f336 Java HotSpot(TM) 64-Bit Server VM 25.40-b25 on 1.8.0_40-b26 +jit [linux-amd64]

# gem install bundler -v 1.10.6
Error: Your application used more memory than the safety cap of 500M.
Specify -J-Xmx####m to increase it (#### = cap size in MB).
Specify -w for full OutOfMemoryError stack trace

# jruby -S -J-Xmx1G gem install bundler -v 1.10.6
Fetching: bundler-1.10.6.gem (100%)
Successfully installed bundler-1.10.6
1 gem installed

Will happily provide any additional info you need.

@donv
Copy link
Member

donv commented Sep 28, 2015

Hopefully useful info from another system where I can install bundler with a cap of 40MB:

$ ruby -v
jruby 9.0.1.0 (2.2.2) 2015-09-02 583f336 Java HotSpot(TM) 64-Bit Server VM 25.60-b23 on 1.8.0_60-b27 +jit [darwin-x86_64]
$ jruby -S -J-Xmx40M gem install bundler -v 1.10.6
Successfully installed bundler-1.10.6
1 gem installed
$ gem list

*** LOCAL GEMS ***

bundler (1.10.6)
jar-dependencies (0.1.15)
jruby-launcher (1.1.1 java)
jruby-openssl (0.9.11 java)
json (1.8.0 java)
minitest (5.4.1)
power_assert (0.2.3)
psych (2.0.15 java)
rake (10.1.0)
rdoc (4.1.0)
ruby-maven (3.3.3)
ruby-maven-libs (3.3.3)
test-unit (3.0.3)

@vassilevsky how many gems do you have installed before trying to install bundler?

@vassilevsky
Copy link
Author

Bundler was the first gem I installed with gem install after installing JRuby itself.

$ gem list

*** LOCAL GEMS ***

bundler (1.10.6)
jar-dependencies (0.1.15)
jruby-launcher (1.1.1 java)
jruby-openssl (0.9.11 java)
json (1.8.0 java)
minitest (5.4.1)
power_assert (0.2.3)
psych (2.0.15 java)
rake (10.1.0)
rdoc (4.1.0)
ruby-maven (3.3.3)
ruby-maven-libs (3.3.3)
test-unit (3.0.3)

@headius
Copy link
Member

headius commented Sep 28, 2015

This is truly bizarre. A few things to do to get us more info:

  1. Add the output of running with -w to get the full OOME stack trace.
  2. Run with -J-Xrunhprof:depth=0 and send the java.hprof.txt file it creates in the current dir. This will show us all objects being allocated.
  3. Try running with --dev which will turn off our JIT compiler (in case it's doing something weird).
  4. Try running JRuby master (rvm install jruby-head, etc) and see if you have the same issue.

@gumayunov
Copy link

The same on jruby 1.7.22 and the same machine as

-bash-4.1$ java -version
java version "1.8.0_40"
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)

-bash-4.1$ ruby -v
jruby 1.7.22 (1.9.3p551) 2015-08-20 c28f492 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_40-b26 +jit [linux-amd64]
-bash-4.1$ sudo  jruby -w -W2 -S gem install bundler -v 1.10.6
Error: Your application used more memory than the safety cap of 500M.
Specify -J-Xmx####m to increase it (#### = cap size in MB).
Exception trace follows:
java.lang.OutOfMemoryError: GC overhead limit exceeded
    at org.joni.OptExactInfo.<init>(OptExactInfo.java:28)
    at org.joni.NodeOptInfo.<init>(NodeOptInfo.java:27)
    at org.joni.Analyser.optimizeNodeLeft(Analyser.java:2132)
    at org.joni.Analyser.optimizeNodeLeft(Analyser.java:1940)
    at org.joni.Analyser.setOptimizedInfoFromTree(Analyser.java:2227)
    at org.joni.Analyser.compile(Analyser.java:157)
    at org.joni.Regex.<init>(Regex.java:162)
    at org.joni.Regex.<init>(Regex.java:139)
    at org.jruby.RubyRegexp.makeRegexp(RubyRegexp.java:149)
    at org.jruby.RubyRegexp.getPreprocessedRegexpFromCache(RubyRegexp.java:194)
    at org.jruby.RubyRegexp.preparePattern(RubyRegexp.java:454)
    at org.jruby.RubyRegexp.search19(RubyRegexp.java:1778)
    at org.jruby.RubyRegexp.matchPos(RubyRegexp.java:1720)
    at org.jruby.RubyRegexp.op_match19(RubyRegexp.java:1657)
    at org.jruby.RubyString.op_match19(RubyString.java:1729)
    at org.jruby.RubyString$INVOKER$i$1$0$op_match19.call(RubyString$INVOKER$i$1$0$op_match19.gen)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:168)
    at rubyjit.Gem::Version$$correct?_027246e44fed7cff5713b367d3c59f87c2ef051b1442407170.__file__(/usr/local/rbenv/versions/jruby-1.7.22/lib/ruby/shared/rubygems/version.rb:172)
    at rubyjit.Gem::Version$$correct?_027246e44fed7cff5713b367d3c59f87c2ef051b1442407170.__file__(/usr/local/rbenv/versions/jruby-1.7.22/lib/ruby/shared/rubygems/version.rb)
    at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:181)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:168)
    at rubyjit.Gem::Version$$initialize_0537124e335883c673438a5935366d82ea462d481442407170.__file__(/usr/local/rbenv/versions/jruby-1.7.22/lib/ruby/shared/rubygems/version.rb:206)
    at rubyjit.Gem::Version$$initialize_0537124e335883c673438a5935366d82ea462d481442407170.__file__(/usr/local/rbenv/versions/jruby-1.7.22/lib/ruby/shared/rubygems/version.rb)
    at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:181)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:168)
    at rubyjit.Gem::Version$$marshal_load_7c467acec05be9856f7d960bdd8dbba2453475a91442407170.__file__(/usr/local/rbenv/versions/jruby-1.7.22/lib/ruby/shared/rubygems/version.rb:261)
    at rubyjit.Gem::Version$$marshal_load_7c467acec05be9856f7d960bdd8dbba2453475a91442407170.__file__(/usr/local/rbenv/versions/jruby-1.7.22/lib/ruby/shared/rubygems/version.rb)
    at org.jruby.internal.runtime.methods.JittedMethod.call(JittedMethod.java:181)
    at org.jruby.RubyClass.smartLoadNewUser(RubyClass.java:1850)
    at org.jruby.runtime.marshal.UnmarshalStream.userNewUnmarshal(UnmarshalStream.java:461)
    at org.jruby.runtime.marshal.UnmarshalStream.unmarshalObjectDirectly(UnmarshalStream.java:263)
    at org.jruby.runtime.marshal.UnmarshalStream.unmarshalObject(UnmarshalStream.java:140)

Option --dev cause no effect. And it works with 1Gb limit:

-bash-4.1$ sudo jruby -J-Xmx1G -S gem install bundler -v 1.10.6
Fetching: bundler-1.10.6.gem (100%)
Successfully installed bundler-1.10.6
1 gem installed

@donv
Copy link
Member

donv commented Oct 26, 2015

Does it work with explicit lower heap size? For example:

sudo jruby -J-Xmx500M -S gem install bundler -v 1.10.6

@vassilevsky
Copy link
Author

Sorry for the late reply. Had to use an older version of JRuby and encountered this issue again. Here are the details:

# uname -a
Linux vm-jenkins.local 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

# java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (rhel-2.5.5.3.el6_6-x86_64 u79-b14)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)

# ruby -v
jruby 1.7.23 (1.9.3p551) 2015-11-24 f496dd5 on OpenJDK 64-Bit Server VM 1.7.0_79-mockbuild_2015_05_14_07_23-b00 +jit [linux-amd64]

# free -m
             total       used       free     shared    buffers     cached
Mem:          3832       2513       1319        128        594        744
-/+ buffers/cache:       1174       2658
Swap:         2015       1042        973

# jruby -J-Xmx500M -w -S gem install bundler
Error: Your application used more memory than the safety cap of 500M.
Specify -J-Xmx####m to increase it (#### = cap size in MB).
Exception trace follows:
java.lang.OutOfMemoryError: Java heap space
    at org.jruby.RubyArray.aryDup19(RubyArray.java:1006)
    at org.jruby.runtime.Helpers.arrayValue(Helpers.java:1826)
    at org.jruby.runtime.Helpers.arrayValue(Helpers.java:1800)
    at org.jruby.runtime.Helpers.splatValue19(Helpers.java:1902)
    at org.jruby.ast.Splat19Node.interpret(Splat19Node.java:48)
    at org.jruby.ast.FCallSpecialArgNode.interpret(FCallSpecialArgNode.java:30)
    at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
    at org.jruby.evaluator.ASTInterpreter.INTERPRET_BLOCK(ASTInterpreter.java:112)
    at org.jruby.runtime.Interpreted19Block.evalBlockBody(Interpreted19Block.java:206)
    at org.jruby.runtime.Interpreted19Block.yield(Interpreted19Block.java:157)
    at org.jruby.runtime.Block.yield(Block.java:142)
    at org.jruby.RubyArray.collect(RubyArray.java:2400)
    at org.jruby.RubyArray.map19(RubyArray.java:2414)
    at org.jruby.RubyArray$INVOKER$i$0$0$map19.call(RubyArray$INVOKER$i$0$0$map19.gen)
    at org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:143)
    at org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:154)
    at org.jruby.ast.CallNoArgBlockNode.interpret(CallNoArgBlockNode.java:64)
    at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
    at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:74)
    at org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:182)
    at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:203)
    at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:168)
    at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
    at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
    at org.jruby.ast.RescueNode.executeBody(RescueNode.java:221)
    at org.jruby.ast.RescueNode.interpret(RescueNode.java:116)
    at org.jruby.ast.BeginNode.interpret(BeginNode.java:83)
    at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
    at org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
    at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:74)
    at org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:182)
    at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:203)

# jruby -J-Xmx500M -J-Xrunhprof:depth=0 -w -S gem install bundler
<see below>

Full output: https://gist.github.com/vassilevsky/838666d4df0649e4ab27
Resulting java.hprof.txt: https://www.dropbox.com/s/moo85drrom5w6uz/java.hprof.txt

Thank you 🙏

@headius
Copy link
Member

headius commented Mar 4, 2016

Anyone still able to reproduce this with JRuby 9.0.5.0?

Another flag that could help us is the JVM flag -XX:+HeapDumpOnOutOfMemoryError (prefixed with -J if passed to JRuby). The resulting heap dump file (should be something fairly obvious and large in current directory) will be easier for us to analyze so we can see what's taking up all the memory.

@vassilevsky Your runhprof output was not as helpful as I'd hoped. :-( It doesn't show enough allocated objects to be a problem, so I'm starting to wonder if this is a native memory or resource leak of some kind.

To anyone that can still reproduce it:

  • Try a clean JRuby install
  • Provide us with OS version, JVM version, JRuby version
  • If you can reproduce in a VM and provide an image, that would be very helpful.

@vassilevsky
Copy link
Author

Yes, it is still there :( But I started suspecting the environment rather than JRuby itself.

@headius
Copy link
Member

headius commented Mar 24, 2016

I was able to install bundler with -Xmx100M on Java 7 and 8, JRuby 9.0.5.0 and JRuby 9.1.0.0. This was on OS X

We're going to need to get a heap dump from your JRuby instance when it's using all that memory, or I don't think we'll be able to investigate it.

Do you have some JRUBY_OPTS in env we're not setting, or some libraries that are getting loaded by some other piece of code?

@headius
Copy link
Member

headius commented Mar 24, 2016

@vassilevsky If you have a few minutes, you could stop into our IRC channel to work through this a bit.

@headius
Copy link
Member

headius commented Apr 20, 2016

Seems environmental and no response from original reporter. Closing for now.

@headius headius closed this as completed Apr 20, 2016
@headius headius added this to the Invalid or Duplicate milestone Apr 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants