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

Jump to bottom

Concurrency issues when preparing IR for interpretation #1793

Closed
headius opened this issue Jul 6, 2014 · 4 comments
Closed

Concurrency issues when preparing IR for interpretation #1793

headius opened this issue Jul 6, 2014 · 4 comments
Labels
ir jit
Milestone
JRuby 9.0.0.0-pre1

Comments

@headius
Copy link
Member

headius commented Jul 6, 2014

Saw this during a spec run today. Actually fired a few times in the same run. This is running with JIT enabled; it's possible the JIT's re-tweaking of the IR is conflicting here?

2014-07-05T20:43:41.598-05:00: IRScope: Error linearizing cfg: 
java.util.ConcurrentModificationException
    at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
    at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
    at org.jruby.ir.util.EdgeTypeIterator.hasNext(EdgeTypeIterator.java:28)
    at org.jruby.ir.util.Vertex.getFirstEdge(Vertex.java:161)
    at org.jruby.ir.util.Vertex.getIncomingSourceDataOfType(Vertex.java:115)
    at org.jruby.ir.representations.CFG.getIncomingSourceOfType(CFG.java:177)
    at org.jruby.ir.representations.CFGLinearizer.linearizeInner(CFGLinearizer.java:56)
    at org.jruby.ir.representations.CFGLinearizer.linearizeInner(CFGLinearizer.java:73)
    at org.jruby.ir.representations.CFGLinearizer.linearizeInner(CFGLinearizer.java:64)
    at org.jruby.ir.representations.CFGLinearizer.linearizeInner(CFGLinearizer.java:68)
    at org.jruby.ir.representations.CFGLinearizer.linearizeInner(CFGLinearizer.java:64)
    at org.jruby.ir.representations.CFGLinearizer.linearize(CFGLinearizer.java:44)
    at org.jruby.ir.IRScope.buildLinearization(IRScope.java:1083)
    at org.jruby.ir.IRScope.setupLinearization(IRScope.java:669)
    at org.jruby.ir.IRScope.prepareInstructionsForInterpretation(IRScope.java:491)
    at org.jruby.ir.IRScope.prepareForInterpretation(IRScope.java:635)
    at org.jruby.ir.IRScope.getInstrsForInterpretation(IRScope.java:1064)
    at org.jruby.ir.interpreter.Interpreter.interpret(Interpreter.java:570)
    at org.jruby.ir.interpreter.Interpreter.INTERPRET_BLOCK(Interpreter.java:693)
    at org.jruby.runtime.InterpretedIRBlockBody.commonYieldPath(InterpretedIRBlockBody.java:47)
headius added a commit that referenced this issue Jul 6, 2014
@headius
Additional synchronization around IRScope preparation (#1793)
93e50c4
@enebo
Copy link
Member

enebo commented Jul 7, 2014

Yeah CFG and LinearCFG are two separate passes. The race seems logical but it also makes me wonder what the best solution is? IRScope data is highly mutable for performance reasons. cloning it all would be expensive. We can sychronize where you suggest and it will probably remove the race (I don't think prepareForinterp and prepareForCompile could possibly overlap for the same method), but we could also perhaps make JIT a worker thread. If we did this then we would limit JIT'ing to a single thread but we would not need to sychronize. I am unclear if that is an issue or not but I think it might remove some more concurrency issues.

@subbuss
Copy link
Contributor

subbuss commented Jul 7, 2014

After chatting with Tom on IM, I am wondering if this is happening because the JIT is trying to compile the same method in different threads?

@enebo
Copy link
Member

enebo commented Jul 7, 2014

It pretty much has to be or two methods are modifying the same CFG which would be a much much worse problem :)

I definitely think controlling JIT by a single worker or coordinated worker pool is the right way to go now. When we get to profiled optimizations and de-optimization this can of worms will just appear in another place if we use synchronized methods. Also this is two threads JIT'ing the same method which is an undesirable outcome.

@enebo enebo added this to the JRuby 9.0.0.0 milestone Jan 15, 2015
@enebo
Copy link
Member

enebo commented Jan 15, 2015

This has been solved for now. Closing.

@enebo enebo closed this as completed Jan 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
ir jit
Projects
None yet
Milestone
JRuby 9.0.0.0-pre1
Development

No branches or pull requests
3 participants
@headius @enebo @subbuss