Summary: | Another LTW Deadlock on Sun VMs | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Ron Bodkin <rbodkin+LISTS> |
Component: | Compiler | Assignee: | Alexandre Vasseur <avasseur> |
Status: | REOPENED --- | QA Contact: | |
Severity: | critical | ||
Priority: | P5 | CC: | dave |
Version: | DEVELOPMENT | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: | |||
Bug Depends on: | 99861 | ||
Bug Blocks: |
Description
Ron Bodkin
2005-09-12 18:34:42 EDT
On looking more closely, it looks like the original work-around is now causing a deadlock. On the other hand, is it really necessary to hold the lock while reading in definitions? Or if it is, why not use class.forName to ensure the needed classes all get loaded before the lock is acquired. Why not construct the Adaptor with no work, then release the locks and initialize the Adaptor? You would then want to synchronize on the init method and before returning the adaptor... to be thread safe you would need to use something like Doug Lea's concurrency library to lock the newly constructed object inside the other synchronized blocks & yet return it after the others finish. Just some thoughts... obviously this is a consequence of the poor hack of #99861 which consist in locking the classloader within which we are weaving to bypass some proven bugs in Sun JSR163 implementation. You may try to remove the fix for 99861 in Aj.java, rebuild, get a fresh Sun VM and try again with Tomcat and let us know. deps A thought: might the issue be with Tomcat? Don't Tomcat application class loaders check their own definitions first, with the result that class inter-dependencies across application class loaders are not serialized as they are under the usual delegation scheme? It would be nice to see this reproduced outside Tomcat. closing this one see deps. Apologies is this comment is posted twice -- I posted a more in-depth comment yesterday which doesn't seem to have appeared yet. I have experienced this problem whilst advising a multi-threaded application on IBM's 5.0 beta SDK and Sun's 5.0. I'm not using tomcat or any other loader. This was on the 3rd Nov development AspectJ build. What is the significance of RESOLVED REMIND? I don't think this has been resolved. Are there plans to fix it? Thanks, Dave Dave Your detailled comment does not appear. Please post it again. RESOLVED REMIND means that this is FIXED and needs to be marked as FIXED when we ship our next official milestone / RC / release (at least I am using this status for that purpose). Please post thread dump and possibly app to reproduce the issue you have on that issue. Hi Alexandre. Thanks for your comment. After you said that you thought it was fixed, I spent a little more time testing. After I tried completely deleting my stable aspectj directory and replacing it with the 3rd Nov development build, the issue went away. I guess I need to learn how this all fits together better :-) Good work, and sorry to waste your time! Dave LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated. |