1 2 3 4 5 Previous Next 67 Replies Latest reply on Apr 4, 2006 7:26 AM by adrian.brock Go to original post
      • 30. Re: JBossRetro weaver issues

        Go ahead.
        I'm just proving concepts (implementing each pattern we see)
        rather than trying to get the full solution in place immediately. :-)

        • 31. Re: JBossRetro weaver issues
          starksm64

          Very good, the http://jira.jboss.com/jira/browse/JBAS-2811 issue is assigned to me now.

          • 32. Re: JBossRetro weaver issues

            The webservices check should be passing now with my latest commits.

            So now we need to stablise the implementation.
            1) Proper implementation of annotations (per classloader cache)
            2) Proper tests for weaved concurrent
            3) More complete tests for everything we weave

            For (2) I suggest we:
            * Take a copy of the concurrent backport tests
            * Convert them back to use java.util.concurrent on JDK5
            * Run them through JBossRetro
            * Run the tests on JDK1.4

            Alternatively, the original public domain JSR tests are available in CVS on Doug Lea's site.
            But some of these are going to fail where the backport doesn't support it (maybe it would
            be good to know what they are?)

            • 33. Re: JBossRetro weaver issues

              Yes, it passed when I tried yesterday.

              I looked briefly at porting the backport tests, but realized this was silly considering the JSR166 tests may just need to be pruned, and we can look to concurrent/tests/tck for guidance on that.

              I'll put the jsr166 tck into jbossretro and modify its cruisecontrol build to run these tests.

              http://gee.cs.oswego.edu/dl/concurrency-interest/

              Once that is in place I think we are ready to make the switch?

              • 34. Re: JBossRetro weaver issues

                Oops, I meant to post the jira task, not the jsr interest site :-)

                http://jira.jboss.com/jira/browse/JBAS-2814

                • 35. Re: JBossRetro weaver issues

                   

                  "ryan.campbell@jboss.com" wrote:

                  Once that is in place I think we are ready to make the switch?


                  Not until the AnnotationHelper understands classloaders and we prune
                  the javassist data. We don't want to be holding the bytecode around for each class,
                  only the annotation attributes.

                  • 36. Re: JBossRetro weaver issues

                     

                    "ryan.campbell@jboss.com" wrote:
                    Oops, I meant to post the jira task, not the jsr interest site :-)

                    http://jira.jboss.com/jira/browse/JBAS-2814


                    I've made these tests compile.
                    1) Adding the non-existant future scheduled classes to org.jboss.test.concurrent
                    2) Commenting out tests for non-existant api
                    3) Adding a pollFirst/Last helper to simulate this method used by the TreeSet test.

                    There are 14 failures running this now against JDK5
                    which I am going to look at next.

                    • 37. Re: JBossRetro weaver issues

                      Upgrading to JDK1.5.0_06 has fixed a lot of them.
                      There is at least one still not fixed:
                      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6327342

                      I am down to 3 failures.

                      • 38. Re: JBossRetro weaver issues

                        Down to one failure:
                        ThreadPooledExectuor::testRejectedRecycledTask
                        This looks broken, but I don't see a bug report on Sun's bug list for it?

                        Running RetroCheck shows *lots* missing.
                        Did you know JDK5 introduced a ThreadLocal.remove()?
                        When do we get ThreadLocal.clear()? ;-)

                        • 39. Re: JBossRetro weaver issues

                          I've made some progress on this today.
                          I'm down to about 90 errors in RetroCheck vs 1000+ this morning.

                          To help I've also introduced the concept of signature fixing

                           // FIXME signatureFixes configurable (and smarter?)
                           Map<String, String> signatureFixes = new HashMap<String, String>();
                           signatureFixes.put("edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantReadWriteLock.writeLock()Ledu/emory/mathcs/backport/java/util/concurrent/locks/ReentrantReadWriteLock$WriteLock;", "()Ledu/emory/mathcs/backport/java/util/concurrent/locks/Lock;");
                           signatureFixes.put("edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantReadWriteLock.readLock()Ledu/emory/mathcs/backport/java/util/concurrent/locks/ReentrantReadWriteLock$ReadLock;", "()Ledu/emory/mathcs/backport/java/util/concurrent/locks/Lock;");
                          
                          


                          This is to support overloaded return types in JDK5,
                          but I should also be able to use this to remove the need to have a wrapper DelayQueue
                          by mapping the methodName(Delayed) to methodName(Object).

                          • 40. Re: JBossRetro weaver issues

                            Some of the lock classes were missing altogether.
                            I've copied Doug Lea's classes into org.jboss.util.concurrent.locks
                            and removed the use of sun.misc.Unsafe.

                            To complete this, we need to emulate this class with some plain synchronization.

                            • 41. Re: JBossRetro weaver issues

                              After some hacking and switching to Doug Lea's version of DelayQueue,
                              I'm down to a few issues.

                              * Unsafe
                              AbstractQueueSynchronizer/ReentrantReadWriteLock/LockSupport
                              all fail because I haven't implemented this

                              * Executors
                              This test is failing because of the invalid assumption about the AccessControlContext
                              (same as the backport tests)

                              * ReentrantLock
                              This is timing out for a reason I haven't investigated

                              * SemaphoreTest
                              This is failing because of unimplemented "query" methods for nonfair queing

                              Other issues.
                              * Signature fixing
                              I backed this modification out because it doesn't work propery

                              * Thread.getId()
                              I've mapped this to Thread.hashCode() which is obviously wrong
                              (there is warning when you run Retro if you use this)

                              * ThreadLocal
                              These tests actually test ThreadLocal.remove() so we would need our own
                              JDK1.4 impl to pass these tests (I removed the tests)

                              * Semaphore multiple permits operations
                              I commented out the tests for this since it is not supported by backport concurrent

                              • 42. Re: JBossRetro weaver issues

                                So except for the Reentrant[ReadWrite]Lock
                                it is looking pretty good.

                                Strangely, the ThreadPoolExectuor test that fails on JDK5
                                doesn't fail in backport concurrent ;-)

                                • 43. Re: JBossRetro weaver issues

                                  So what should I do with this?

                                  Should I putback backport-concurrent-util's ReentrantReadWriteLock
                                  with less coverage and no support for the AbstractQueueSynchronizer or LockSupport
                                  or should I try to implement Unsafe?

                                  I doubt I am going to get around to implementing Unsafe in the next few weeks.

                                  • 44. Re: JBossRetro weaver issues

                                    Could we have an exception list in the jbossretro which would fail the weaving if any unimplemented/untested classes were used?