Excess threads reporting on deadlock

[Keith McGuigan]

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: david.holmes at sun.com; serviceability-dev at openjdk.java.net
> From: keith.mcguigan at oracle.com
> To: dmytro_sheyko at hotmail.com
> 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: dmytro_sheyko at hotmail.com
> To: david.holmes at sun.com
> Subject: RE: Excess threads reporting on deadlock
> Date: Mon, 31 Jan 2011 16:48:55 +0700
> CC: serviceability-dev at openjdk.java.net
>
> 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: David.Holmes at Sun.COM
> > Subject: Re: Excess threads reporting on deadlock
> > To: dmytro_sheyko at hotmail.com
> > CC: serviceability-dev at openjdk.java.net
> >
> > 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 
> >
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20110131/8878f570/attachment.html