Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Loadtime Weaving Deadlock 
Hi Matthew our site is back up. We've been contending with JVM crashes from our use of Glassbox and AJ on Linux. See bugs.sun.com bug # 6526904. This latter bug occurs after days of use but started only after we installed Glassbox and AJ
Sent wirelessly via BlackBerry from T-Mobile.  

-----Original Message-----
From: Matthew Webster <matthew_webster@xxxxxxxxxx>
Date: Fri, 2 Mar 2007 11:53:48 
To:AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>
Subject: RE: [aspectj-dev] Loadtime Weaving Deadlock

Ron, 
 
>I’m looking at the code for Sun’s 1.5.0_09 VM and there’s no synchronized block in verifySubclass. Instead it is invoking concurrent map methods like >putIfAbsent. So perhaps they improved this behavior during the development cycle of Java 1.5. So apparently this is also a bug in earlier 1.5 VMs. 
You are right. I was looking at 1.5.0_05. I have now upgraded. 
 
>I do like your idea of avoiding the problem by not reading this information if not needed. However, it does still leave a risk of deadlock when printing weaving >information. It would prefer to just not read this information when load-time weaving, given the risk of deadlock. Is this information also exposed for use >reflectively at runtime via thisJoinPoint? Minimally, it seems like there should be a flag to avoid the problem. 
This sort of thing should really be transparent to the user. We have -X and -Xlint options to cope with instability in new options but I don't like the idea of using them to workaround the shortcomings in old JDKs. However the modifications required will be non-trivial as I have just discovered from the number of failures in the test caused by simply ignoring the source location information. 
 
The Glassbox forums seem to be out of action so I will comment on your suggest WRT ObjectInputStream when they are available. 
 
Matthew Webster
 AOSD Project
 Java Technology Centre, MP146
 IBM United Kingdom Limited
 Hursley Park, Winchester,  SO21 2JN, England
 Telephone: +44 196 2816139 (external) 246139 (internal) 
 
 
 
 "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx> 
Sent by: aspectj-dev-bounces@xxxxxxxxxxx 
28/02/2007 18:14 
 
Please respond to
 AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx> 
 
 
To "'AspectJ developer discussions'" <aspectj-dev@xxxxxxxxxxx> 
 
cc 
 
Subject RE: [aspectj-dev] Loadtime Weaving Deadlock 
 
 
 
 
 
Hi Matthew, 
  
I’m looking at the code for Sun’s 1.5.0_09 VM and there’s no synchronized block in verifySubclass. Instead it is invoking concurrent map methods like putIfAbsent. So perhaps they improved this behavior during the development cycle of Java 1.5. So apparently this is also a bug in earlier 1.5 VMs. 
  
I see your point about the problem with my workaround idea: the system is loading a user-defined subclass of ObjectInputStream to verify it, so it’s not possible to know what subclass(es) to preload. My mistake. 
  
I do like your idea of avoiding the problem by not reading this information if not needed. However, it does still leave a risk of deadlock when printing weaving information. It would prefer to just not read this information when load-time weaving, given the risk of deadlock. Is this information also exposed for use reflectively at runtime via thisJoinPoint? Minimally, it seems like there should be a flag to avoid the problem. 
  
Another option might be to exclude subclasses of ObjectInputStream from weaving: that’s probably a good workaround for our needs… 
  
 
 
----------------
 
From: aspectj-dev-bounces@xxxxxxxxxxx [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Matthew Webster
 Sent: Wednesday, February 28, 2007 3:54 AM
 To: AspectJ developer discussions
 Subject: Re: [aspectj-dev] Loadtime Weaving Deadlock 
  

 Ron, 
 
 I am puzzled that you think this problem has gone away in JDK 1.5. A quick look at the code shows a synchronized block in ObjectInputStream.verifySubclass() using a static variable so the same global lock would seem to still exist. I am also puzzled by your suggested solution. I am not sure how you could persuade serialization to preload classes because you don't know what they are until you read the object stream. 
 
 A quick search of the weaver module shows that ResolvedTypeMunger is the only a single use of ObjectStreamClass. Perhaps if this information is only needed for weaveinfo messages then when that option is not used we could avoid reading it. There is already a check to avoid reading the attribute for aspects built with versions of AspectJ older than 1.5. 
 
 Matthew Webster
 AOSD Project
 Java Technology Centre, MP146
 IBM United Kingdom Limited
 Hursley Park, Winchester,  SO21 2JN, England
 Telephone: +44 196 2816139 (external) 246139 (internal) 
 
 
 "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx> 
 Sent by: aspectj-dev-bounces@xxxxxxxxxxx 
27/02/2007 16:43 
 
 
 
Please respond to
 AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx> 
 
 
 
To "'AspectJ developer discussions'" <aspectj-dev@xxxxxxxxxxx> 
 
cc   
 
Subject [aspectj-dev] Loadtime Weaving Deadlock 
  
 
 
     
 

 
 
 Two of our users have reported a deadlock in load-time weaving on a 1.4 VM, e.g., see  <http://www.glassbox.com/forum/forum/viewthread?thread=146> http://www.glassbox.com/forum/forum/viewthread?thread=146 
  
 This happens in a 1.4 VM because ObjectInputStream locks sun.misc.SoftCache (used to hold verified subclasses), whereas in 1.5 they use a ConcurrentHashMap so you don’t get the deadlocking behavior. I’m thinking that the best fix for this is to somehow force ObjectInputStream to load a class before weaving so that it won’t trigger class loading during weaving. This would be a fix/work-around in the 1.4 VM adapter we’re using, so it’s not an AspectJ issue per se, but I’d value input on how to best resolve this. 
  
 Thanks, 
 Ron 
 _______________________________________________
 aspectj-dev mailing list
 aspectj-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/aspectj-dev
 
 
 
 
 
----------------
 
  
Unless stated otherwise above:
 IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
 Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 

 
 
 _______________________________________________
 aspectj-dev mailing list
 aspectj-dev@xxxxxxxxxxx
 https://dev.eclipse.org/mailman/listinfo/aspectj-dev
 

 

 
----------------

 
 
Unless stated otherwise above:
 IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
 Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 

 
 
 

 _______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

Back to the top