Concurrency issues when preparing IR for interpretation

[headius]

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]

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]

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]

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]

This has been solved for now. Closing.