Keith, Have you tried to re-open the bug? I can't see changes in its status.
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 11:09:13 -0500 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>
