-
30. Re: JBossRetro weaver issues
adrian.brock Feb 15, 2006 10:46 AM (in response to starksm64)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 Feb 15, 2006 10:50 AM (in response to starksm64)Very good, the http://jira.jboss.com/jira/browse/JBAS-2811 issue is assigned to me now.
-
32. Re: JBossRetro weaver issues
adrian.brock Feb 15, 2006 5:36 PM (in response to starksm64)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
ryan.campbell Feb 16, 2006 6:28 PM (in response to starksm64)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
ryan.campbell Feb 16, 2006 6:31 PM (in response to starksm64)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
adrian.brock Feb 17, 2006 5:12 AM (in response to starksm64)"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
adrian.brock Feb 20, 2006 8:26 AM (in response to starksm64)"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
adrian.brock Feb 20, 2006 10:52 AM (in response to starksm64)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
adrian.brock Feb 20, 2006 11:55 AM (in response to starksm64)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
adrian.brock Feb 21, 2006 11:59 AM (in response to starksm64)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
adrian.brock Feb 21, 2006 12:00 PM (in response to starksm64)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
adrian.brock Feb 22, 2006 12:00 PM (in response to starksm64)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
adrian.brock Feb 22, 2006 12:01 PM (in response to starksm64)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
adrian.brock Mar 2, 2006 7:33 AM (in response to starksm64)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
ryan.campbell Mar 6, 2006 1:29 PM (in response to starksm64)Could we have an exception list in the jbossretro which would fail the weaving if any unimplemented/untested classes were used?