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
