You'll have to excuse me while I struggle to remember the details of
this one, but I believe that the deadlock detection code in the VM
only detects the existence of a deadlock when it happens, but it
doesn't know which threads are a part of it. Any thread that is
currently blocked is a potential contributor to the deadlock, so the
VM prints out information about all the blocked threads so that the
developer can determine where the deadlock is and how to fix it. I
could be wrong about this -- it's been a while since I looked at it.
Again, IMO, this ought to be fine, but I understand if you've got lots
of blocked threads than you might have a lot of extra data to slog
through. I can re-open the bug if you like (perhaps as an RFE?), but
it's not likely to be a high enough priority to be "fixed" anytime in
the near future. Unless someone wants to investigate the code to find
and suggest a fix (hint, hint).
--
- Keith
On Jan 31, 2011, at 10:20 AM, Dmytro Sheyko wrote:
Hi Keith,
Thank you for information about this bug.
May I convince you of the need for fixing it?
"The more the better" approach does not go well here.
Doesn't it make sense to report all threads (including even not
blocked ones)?
Analyzing deadlock it's important to know threads that form cycle.
The problem is almost always in code that these threads execute.
Other threads just hinder analysis. But if I need them I can use
other API that gives me the list of all threads.
However, existing behavior does not even follow "the more the
better" approach properly.
Sometimes the deadlock is reported as (A, B, C), sometimes as (B, C,
D) and as (B, ะก), but never as (A, B, C, D).
The set of threads that are reported is not clearly defined.
Thanks,
Dmytro
CC: [email protected]; [email protected]
From: [email protected]
To: [email protected]
Subject: Re: Excess threads reporting on deadlock
Date: Mon, 31 Jan 2011 07:57:00 -0500
Hi Dmytro -
This bug was marked 'closed' because the behavior noted is
intentional and we do not believe it should be changed. When an
error situation such as a deadlock occurs we want the developer to
have as much information as possible to help resolve the issue.
--
- Keith
On Jan 31, 2011, at 4:52 AM, Dmytro Sheyko wrote:
Corrections: I am about this one:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6850341
From: [email protected]
To: [email protected]
Subject: RE: Excess threads reporting on deadlock
Date: Mon, 31 Jan 2011 16:48:55 +0700
CC: [email protected]
Hi,
I just noticed that the bug report is closed. Can I know why?
Thanks,
Dmytro
> Date: Fri, 5 Jun 2009 03:41:17 +1000
> From: [email protected]
> Subject: Re: Excess threads reporting on deadlock
> To: [email protected]
> CC: [email protected]
>
> Hi Dmytro,
>
> Thanks for submitting these. I just wanted to say that a lack of
immediate
> response on the mailing lists does not mean noone is, or will,
look at
> these, but it may be a while before people have the cycles to do so.
> Certainly this week is not a good week :)
>
> David Holmes (from JavaOne)
>
> Dmytro Sheyko wrote:
> > Hi,
> >
> > Another one patch about deadlock detection:
> >
> > Excess threads reporting on deadlock
> > https://bugs.openjdk.java.net/show_bug.cgi?id=100065
> >
> > --
> > Dmytro Sheyko
> >
------------------------------------------------------------------------
> > Invite your mail contacts to join your friends list with Windows
Live
> > Spaces. It's easy! Try it!
> > <http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
>
