Yao Qi wrote:
>> We are writing a tool to check the events among threads in the
>> application, and synchronization event is one of these events. We want
>> to know something like this, Thread A calls notify() and then Thread B
>> is waken up from wait() by Thread A.
> Possibly most accurate approach would be to provide your own
> implementation of java.lang.Object to the JVM (using e.g.
> -Xbootclasspath/p:... option) which will record all calls of wait(),
> notify() and notifyAll(), together with a references to the object and a
> current thread info. And then analyze recorded entries.
>> and could we get the information of "wait set"?
> Examine the code from there:
> http://groups.google.com/group/comp.lang.java.programmer/msg/5d7d2ade8ecdaec1
Woudln't the JPDA help? It's supposed to have low-level hooks for all kinds
of stuff in there. I do not know if it will help with your thread needs, but
it's one place I'd research if I were writing such a tool.
<http://java.sun.com/j2se/1.5.0/docs/guide/jpda/jpda.html>
I imagine you could write a tool that sets breakpoints on the Object thread
calls of interest and then "checks" the "events" before returning control to
the target app.

Signature
Lew
>> We are writing a tool to check the events among threads in the
>> application, and synchronization event is one of these events. We
[quoted text clipped - 7 lines]
> wait(), notify() and notifyAll(), together with a references to the
> object and a current thread info. And then analyze recorded entries.
I think Bytecode instrumentation could do the same thing as your
mentioned above, and currently, we are using ASM to do instrumentation.
I think the only problem in on notify(), because one thread is picked up
from "wait set", and is resumed to run, but we could not know which thread is
picked up and resumed to run.
I still thinking how to solve this problem by means of instrumentation.
>> There is a concept "wait set" in JVM spec,
>>
[quoted text clipped - 4 lines]
> Examine the code from there:
> http://groups.google.com/group/comp.lang.java.programmer/msg/5d7d2ade8ecdaec1
I read that code before, and that code is based on jdk 6. However, our
target jdk is jdk 5.

Signature
Yao Qi <qiyaoltc@gmail.com> GNU/Linux Developer
http://duewayqi.googlepages.com/
"Computers and autmation have become so ingrained and essentaial to day-to-day business that a sensible business should not rely on a single vendor to provide essential services........Thus is is always in a customers' interests to demand that the software they deploy be based on non-proprietary platforms."
-- Brian Behlendorf on OSS (Open Sources, 1999 O'Reilly and Associates)
Piotr Kobzda - 18 May 2007 15:48 GMT
> I think Bytecode instrumentation could do the same thing as your
> mentioned above, and currently, we are using ASM to do instrumentation.
Yes. But I'm afraid that it won't work in your situation.
To wrap the original native methods of Object, there is required support
for a native methods prefix change, which is a new instrumentation 1.6
feature (setNativeMethodPrefix()).
> I think the only problem in on notify(), because one thread is picked up
> from "wait set", and is resumed to run, but we could not know which thread is
> picked up and resumed to run.
For me, it seams to be easiest part of your problem. Patricia already
suggested a solution based on queues. You may also consider using a Map
of Sets of Threads keyed by objects for which wait() has been called.
Or develop some other method...
> I still thinking how to solve this problem by means of instrumentation.
I think it's impossible because of the following requirement:
> our
> target jdk is jdk 5.
With that, probably the only way to solve it, is to use JPDA (already
pointed out by Lew).
piotr