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

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

Comments

@headius
Copy link
Member

@headius 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)
@enebo
Copy link
Member

@enebo 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 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 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 enebo commented Jan 15, 2015

This has been solved for now. Closing.

@enebo enebo closed this as completed Jan 15, 2015
@headius headius removed this from the JRuby 9.0.0.0 milestone Jan 16, 2015
@headius headius added this to the JRuby 9.0.0.0-pre1 milestone Jan 16, 2015
@headius headius added this to the JRuby 9.0.0.0-pre1 milestone Jan 16, 2015
@headius headius removed this from the JRuby 9.0.0.0 milestone Jan 16, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants