-
Bug
-
Resolution: Duplicate
-
P3
-
9
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8038586 | 8u40 | Vladimir Ivanov | P3 | Closed | Duplicate |
Charles Nutter reports:
I can reproduce this by running a fairly normalish command in JRuby:
(Java::JavaLang::InternalError)
guard=Lambda(a0:L,a1:L,a2:L,a3:L,a4:L)=>{
t5:I=MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)boolean(a1:L,a2:L,a3:L,a4:L);
t6:L=MethodHandleImpl.selectAlternative(t5:I,(MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)IRubyObject),(MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)IRubyObject));
t7:L=MethodHandle.invokeBasic(t6:L,a1:L,a2:L,a3:L,a4:L);t7:L}
I think it's happening at an OutOfMemory event (bumping up memory
makes it go away), so it may not be a critical issue, but I thought
I'd toss it out here.
I do not...but it appears to be tied to getting an OOM when inside lambda code.
We now have a third-party report of the same issue. Because the
internal error appears to nuke the original exception, we don't know
for sure that this is memory-related, but the user did see *other*
threads raise OOM and increasing memory solved it.
https://github.com/jruby/jruby/issues/1014
So...there's two things that are bad things here...
* More memory required when running with indy versus without, all
other things kept constant (reproduced by two people, one of them me)
* InternalError bubbling out and swallowing the cause (reproduced by
the same two people)...this may count as two issues.
My original reproduction did not appear to fire on Java 8, but it also
appeared to run forever...so it's possible that we were at a specific
memory threshold (permgen? normal heap? meatspace?) or Java 8 may be
failing more gracefully.
Feel free to discuss or offer suggestions to Alex on the bug report
above. I will be monitoring.
I can reproduce this by running a fairly normalish command in JRuby:
(Java::JavaLang::InternalError)
guard=Lambda(a0:L,a1:L,a2:L,a3:L,a4:L)=>{
t5:I=MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)boolean(a1:L,a2:L,a3:L,a4:L);
t6:L=MethodHandleImpl.selectAlternative(t5:I,(MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)IRubyObject),(MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)IRubyObject));
t7:L=MethodHandle.invokeBasic(t6:L,a1:L,a2:L,a3:L,a4:L);t7:L}
I think it's happening at an OutOfMemory event (bumping up memory
makes it go away), so it may not be a critical issue, but I thought
I'd toss it out here.
I do not...but it appears to be tied to getting an OOM when inside lambda code.
We now have a third-party report of the same issue. Because the
internal error appears to nuke the original exception, we don't know
for sure that this is memory-related, but the user did see *other*
threads raise OOM and increasing memory solved it.
https://github.com/jruby/jruby/issues/1014
So...there's two things that are bad things here...
* More memory required when running with indy versus without, all
other things kept constant (reproduced by two people, one of them me)
* InternalError bubbling out and swallowing the cause (reproduced by
the same two people)...this may count as two issues.
My original reproduction did not appear to fire on Java 8, but it also
appeared to run forever...so it's possible that we were at a specific
memory threshold (permgen? normal heap? meatspace?) or Java 8 may be
failing more gracefully.
Feel free to discuss or offer suggestions to Alex on the bug report
above. I will be monitoring.
- backported by
-
JDK-8038586 OOME on JRuby tests
- Closed
- duplicates
-
JDK-8046703 JEP 210: LambdaForm Reduction and Caching
- Closed
-
JDK-8046703 JEP 210: LambdaForm Reduction and Caching
- Closed