By the way, excluding ObjectInputStream+
from weaving works around the deadlock issue for us.
From: aspectj-dev-bounces@xxxxxxxxxxx
[mailto:aspectj-dev-bounces@xxxxxxxxxxx] On
Behalf Of Matthew Webster
Sent: Friday, March 02, 2007 3:54
AM
To: AspectJ
developer discussions
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
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
