Having done a few more runs, the test deaths seem to arise out of random places in the execution. Sometime the test will die at one point in execution, but pass that same point in the next execution to die at another point. This may indicate that this is a multithreaded issue.
I will have to figure out how to isolate the problem. Peter -----Original Message----- From: Peter K Chan [mailto:[EMAIL PROTECTED] Sent: Monday, May 26, 2008 12:43 PM To: [email protected] Subject: [jruby-dev] Regression in Truck: ReturnJump I recently updated my local copy of JRuby trunk and tested my app against it, and I am seeing test failure. I run a single JUnit wrapper for all my Ruby test cases, and my test is dying from a org.jruby.exceptions.JumpException$ReturnJump, with no stack trace. By method of elimination, my app passed the test in revision 6753, but failed on revision 6754. Here is the change log for the offending revision: === Various optimizations in pursuit of less VM deoptz: * Support a straight-in path for zero-arity calling of compiled code to avoid an extra hop through DynamicMethod.call * Cache a single ReturnJump per thread, updated immediately before being thrown, to slightly reduce the cost of non-local returns * Add more specific/direct calls to the pre/post methods for Java/Compiled method, to avoid the polymorphic calls to CallConfig. Also make direct calls for interpreted code. JIT still uses polymorphic CallConfig.pre/post for now. === I am still investigating this, but I hope that someone can just spot the problem based on the symptom and change log entry. I will post update as I find out more. Peter --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
