Forum: JRuby Curious `java.lang.InternalError: collect=Lambda(a0:L,a1:L,a2:L,a3:L,a4:L)` on 1.7.4

D565139dbbafc06e7daf4826ca0f0228?d=identicon&s=25 R. Tyler Croy (Guest)
on 2013-09-30 18:07
(Received via mailing list)
Attachment: signature.asc (197 Bytes)
I'm seeing this error sporadically, and haven't yet found a good
reproduction
case. For some background I'm using JRuby 1.7.4, Datamapper 1.2.0 and
Puma
2.4.0 inside of a warbled up jar file.

The full stacktrace can be found here:
<https://gist.github.com/rtyler/7ce7e318244ec0c604a4>

Most of the time the application runs just fine. This is the second time
I've
seen this specific error though, which has a habit of only showing up
when
important people are using the app ;)

Any hints/tips for hunting down or even trying to reproduce this bug?


Cheers
- R. Tyler Croy
070009144cf8801e53ea19f9b7cf5d2f?d=identicon&s=25 Ben Porterfield (Guest)
on 2013-09-30 18:52
(Received via mailing list)
I'm also seeing these on a few clients with JRuby 1.7.4 and an older
version of Puma. So far I've only seen the error output on Sun java:

java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
D565139dbbafc06e7daf4826ca0f0228?d=identicon&s=25 R. Tyler Croy (Guest)
on 2013-09-30 19:07
(Received via mailing list)
Attachment: signature.asc (197 Bytes)
On Mon, 30 Sep 2013, Ben Porterfield wrote:

> I'm also seeing these on a few clients with JRuby 1.7.4 and an older
> version of Puma. So far I've only seen the error output on Sun java:
>
> java version "1.7.0_40"
> Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)


We're also using that same version of the JRE.


Around the same time that the java.lang.InternalError popped up, I
noticed the
process was brushing up against the PermGen limits of the JVM. For
example:

    2013-09-30 16:25:48 +0000: Rack app error: java.lang.InternalError:
identity=Lambda(a0:L,a1:L)=>{
        t2:L=Species_L.argL0(a0:L);
        t3:L=ValueConversions.identity(t2:L);t3:L}
    2013-09-30 16:25:50 +0000: Read error: java.lang.OutOfMemoryError:
PermGen space
    jar:file:/tmp/jruby9134330810244587977extract/jruby-stdlib-1.7.4.jar!/META-INF/jruby.home/lib/ruby/1.9/rake/task.rb:1
    68 warning: singleton on non-persistent Java type
Java::JavaLang::OutOfMemoryError (http://wiki.jruby.org/Persistence
    )
    rake aborted!
    PermGen space


Looking through our monitoring, I can see the PermGen seems to spike up
a
little bit every now and again, and the latest spike was around the same
time
that the first linked traceback occurred.


Cheers
- R. Tyler Croy
302c6c56b99912a673f1213b0709c902?d=identicon&s=25 Alex Tambellini (Guest)
on 2013-09-30 19:12
(Received via mailing list)
So you are hitting this bug because jruby 1.7.4 will turn invokedynamic
on when running against jdk7u40 and invokedynamic needs more memory:

https://github.com/jruby/jruby/issues/1014

jruby 1.7.5 will fix this by disabling invokedynamic until jdk8 and
until then you can just disable invokedynamic on jruby .7.4 by adding
-Xcompile.invokedynamic=false to your JRUBY_OPTS.
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-10-01 06:56
(Received via mailing list)
It would also be helpful to know if setting permgen higher makes this
go away for you folks seeing the error. Use flags:

to JRuby (or JRUBY_OPTS): -J-XX:MaxPermSize=256M (or larger...default
is like 64M or something)
to Java (or JAVA_OPTS): same without the -J

- Charlie
070009144cf8801e53ea19f9b7cf5d2f?d=identicon&s=25 Ben Porterfield (Guest)
on 2013-10-02 00:40
(Received via mailing list)
On our clients we opted to turn off invokeddynamic for now, since that
seemed to be a sure way to resolve the problem and they were complaining
about being down (server freeze when problem appears).

 We're trying to find a way to reliably reproduce in-house. If we can,
we'll test the increased MaxPermSize.


On Mon, Sep 30, 2013 at 9:55 PM, Charles Oliver Nutter
F1d37642fdaa1662ff46e4c65731e9ab?d=identicon&s=25 Charles Nutter (headius)
on 2013-10-02 07:48
(Received via mailing list)
Thanks Ben. Nobody is more frustrated about the interminable issues
with invokedynamic in Java 7, but Java 8 seems to be fixing all of
them (again). For most folks I've talked to, permgen increase has made
the issue go away. That doesn't mean it's not an issue (indy logic
shouldn't fall apart when it hits memory limits) but it's a problem
that will fix itself (or be very rare) when permgen goes away in 8

- Charlie

On Tue, Oct 1, 2013 at 5:38 PM, Ben Porterfield
Da9263cedcb39547f599a00188b5cbd8?d=identicon&s=25 Jochen Theodorou (Guest)
on 2013-10-02 12:57
(Received via mailing list)
Am 02.10.2013 07:46, schrieb Charles Oliver Nutter:
> Thanks Ben. Nobody is more frustrated about the interminable issues
> with invokedynamic in Java 7, but Java 8 seems to be fixing all of
> them (again). For most folks I've talked to, permgen increase has made
> the issue go away. That doesn't mean it's not an issue (indy logic
> shouldn't fall apart when it hits memory limits) but it's a problem
> that will fix itself (or be very rare) when permgen goes away in 8

which doesn't mean that the metaspace implementation is without error,
as our users found out already
(https://bugs.openjdk.java.net/browse/JDK-8025635).

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.