[concurrency-interest] Joint Talk for JavaOne?

Mohan Radhakrishnan radhakrishnan.mohan at gmail.com
Sun Apr 8 23:23:28 EDT 2012


I could look at the first deadlock by dumping locks and threads. I was
planning to find the next one using Java Path Finder but I think it is not
recommended for such a big codebase. I am not sure. Its heuristics might
take too much memory.

Mohan

On Mon, Apr 9, 2012 at 3:59 AM, <mabrouk2005 at gmail.com> wrote:

> Nice exercise Dr Heinz,
>
> As others mentioned there were 2 kind of deadlocks the first one was
> very is easy to find via jconsole so likeI thought that was it and
> went and fixed that but then when ran it again it hang it so I knew
> thee was more. the interesting thing the jconsole did not detect the
> AWT deadlock it showed no deadlock even though the app hang. I had to
> force stack dump and get clues to where is the deadlock. Does anyone
> have experienced something like this with jconsole not detecting AWT
> deadlocks?
>
> Thanks again for the nice exercise and the great java news letter I am
> a big fan.
>
> Cheers,
> Mabrouk
>
> On Sat, Apr 7, 2012 at 7:42 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> > No, it's more an AWRY or Java2D bug.
> >
> > Rémi
> >
> > Sent from my Phone
> >
> >
> > ----- Reply message -----
> > From: "Ben Evans" <benjamin.john.evans at gmail.com>
> > To: "Dr Heinz M. Kabutz" <heinz at javaspecialists.eu>
> > Cc: "Rémi Forax" <forax at univ-mlv.fr>, <
> concurrency-interest at cs.oswego.edu>
> > Subject: [concurrency-interest] Joint Talk for JavaOne?
> > Date: Sat, Apr 7, 2012 10:43
> >
> >
> > Heinz, was this with the new jdk8 + lambda build?
> >
> > If so, we should report this crash back to lambda-dev.
> >
> > Thanks,
> >
> > Ben
> >
> > On Sat, Apr 7, 2012 at 11:17 AM, Dr Heinz M. Kabutz
> > <heinz at javaspecialists.eu> wrote:
> >> I see JDK8 crashes even with the vanilla Java2Demo from JDK 1.6.  I see
> >> that
> >> the Java2Demo has been removed from the demos folder of JDK 1.7 and 1.8.
> >>  It
> >> thus is a Java 8 issue, rather than the changes I made to the code.
> >>  Thanks
> >> for the warning Rémi.
> >>
> >>
> >> Regards
> >>
> >> Heinz
> >> --
> >> Dr Heinz M. Kabutz (PhD CompSci)
> >> Author of "The Java(tm) Specialists' Newsletter"
> >> Sun Java Champion
> >> IEEE Certified Software Development Professional
> >> http://www.javaspecialists.eu
> >> Tel: +30 69 75 595 262
> >> Skype: kabutz
> >>
> >>
> >> On 4/6/12 1:51 AM, Rémi Forax wrote:
> >>>
> >>> jdk8 crashes if I click on images of the tapped pane.
> >>>
> >>> Rémi
> >>>
> >>> On 04/05/2012 10:35 PM, Dr Heinz M. Kabutz wrote:
> >>>>
> >>>> Yes, you are correct.
> >>>>
> >>>> However, the mistake most programmers make is to #1 scratch around in
> >>>> the
> >>>> source code to try and discover the problem and #2 then fix it without
> >>>> really understanding what they are doing.  I think the lesson is
> bigger
> >>>> if
> >>>> we give them the source code.  In addition, it is probably more
> >>>> difficult to
> >>>> solve if you have the sources to muse over.
> >>>> Regards
> >>>>
> >>>> Heinz
> >>>> --
> >>>> Dr Heinz M. Kabutz (PhD CompSci)
> >>>> Author of "The Java(tm) Specialists' Newsletter"
> >>>> Sun Java Champion
> >>>> IEEE Certified Software Development Professional
> >>>> http://www.javaspecialists.eu
> >>>> Tel: +30 69 75 595 262
> >>>> Skype: kabutz
> >>>>
> >>>>
> >>>> On 4/5/12 11:30 PM, Nathan Reynolds wrote:
> >>>>>
> >>>>> I guess it is a good idea to not initially include the source code in
> >>>>> the workshop because many times I initially don't have the source
> code
> >>>>> when
> >>>>> trying to figure out performance or scalability problems.
> >>>>>
> >>>>> Nathan Reynolds
> >>>>> <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
> >>>>> Consulting
> >>>>> Member of Technical Staff | 602.333.9091
> >>>>> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server
> Technology
> >>>>>
> >>>>> On 4/5/2012 1:22 PM, Dr Heinz M. Kabutz wrote:
> >>>>>>
> >>>>>> Sorry Nathan, here is the zip file including the source code an an
> Ant
> >>>>>> script to build the code.  Sorry for accidentally excluding that
> from
> >>>>>> the
> >>>>>> file I sent earlier.  The problem was between the chair and the
> >>>>>> keyboard.
> >>>>>>  However, one should be able to pinpoint the deadlock without
> seeing a
> >>>>>> line
> >>>>>> of code.  At the workshop I presented in Spain last week, most of
> the
> >>>>>> programmers immediately started delving into the code before they
> knew
> >>>>>> where
> >>>>>> to look.
> >>>>>> Regards
> >>>>>>
> >>>>>> Heinz
> >>>>>> --
> >>>>>> Dr Heinz M. Kabutz (PhD CompSci)
> >>>>>> Author of "The Java(tm) Specialists' Newsletter"
> >>>>>> Sun Java Champion
> >>>>>> IEEE Certified Software Development Professional
> >>>>>> http://www.javaspecialists.eu
> >>>>>> Tel: +30 69 75 595 262
> >>>>>> Skype: kabutz
> >>>>>>
> >>>>>> On 4/5/12 10:29 PM, Nathan Reynolds wrote:
> >>>>>>>
> >>>>>>> I took the bait and tried out the demo on HotSpot 7 Update 3.  It
> >>>>>>> didn't deadlock for a minute or two.  Then the application froze.
>  I
> >>>>>>> then
> >>>>>>> used jstack to dump the call stacks.  At the end of the report, it
> >>>>>>> said
> >>>>>>> "Found one Java-level deadlock".  It then dumped out the locks and
> >>>>>>> threads
> >>>>>>> involved in the deadlock.  I never looked at the source code... in
> >>>>>>> fact it
> >>>>>>> wasn't in the zip file.  This took about 5-7 minutes from starting
> >>>>>>> the
> >>>>>>> application to finding the deadlock in the call stacks.
> >>>>>>>
> >>>>>>> A 100 good Java developers?  Really?  I guess I can understand.
>  Most
> >>>>>>> engineers don't understand locks.  Most of the time I get answers
> >>>>>>> like one
> >>>>>>> should put a lock around shared variables.  This is accurate but
> they
> >>>>>>> can't
> >>>>>>> really go any deeper.
> >>>>>>>
> >>>>>>> It sounds like the material of your presentation should be very
> good.
> >>>>>>>  It covers things that the deadlock detection tool probably can't
> >>>>>>> figure
> >>>>>>> out.
> >>>>>>>
> >>>>>>> So, it seems like you have everything figured out.  Why do you need
> >>>>>>> someone else?
> >>>>>>>
> >>>>>>> Nathan Reynolds
> >>>>>>> <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
> >>>>>>> Consulting
> >>>>>>> Member of Technical Staff | 602.333.9091
> >>>>>>> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server
> >>>>>>> Technology
> >>>>>>>
> >>>>>>> On 4/5/2012 12:03 PM, Dr Heinz M. Kabutz wrote:
> >>>>>>>>
> >>>>>>>> Hi Nathan,
> >>>>>>>>
> >>>>>>>> a stack trace will only show you a certain class of obvious
> >>>>>>>> deadlocks
> >>>>>>>> that are easy to find and solve.  I remember solving deadlocks
> >>>>>>>> /before/ we
> >>>>>>>> had the brilliant deadlock detection tool in the ThreadMXBean.
>  Yes,
> >>>>>>>> the
> >>>>>>>> deadlock detection tool shows you /some/ deadlocks, but definitely
> >>>>>>>> not all
> >>>>>>>> of them.  I can think of a bunch that it would not find:
> >>>>>>>>
> >>>>>>>> 1. Semaphores running out of permits
> >>>>>>>> 2. ReadWriteLocks trying to upgrade from write lock to read lock
> >>>>>>>> 3. Resource deadlocks
> >>>>>>>>
> >>>>>>>> And some others that I will not describe in detail, such as some
> >>>>>>>> nasty livelocks that we can cause which will hang up the JVM :-)
> >>>>>>>>
> >>>>>>>> I agree with Kirk - it should probably be a 3 hour workshop.  I've
> >>>>>>>> done this three times now - twice in Spain and once via webinar.
> >>>>>>>>  The
> >>>>>>>> workshop would involve some lessons on deadlocks, what causes them
> >>>>>>>> and how
> >>>>>>>> we can prevent them.  Also an explanation as to why we see them so
> >>>>>>>> seldom in
> >>>>>>>> real production.  I've got material prepared for this workshop.
>  And
> >>>>>>>> then a
> >>>>>>>> practical part to the workshop where they can try to find a
> deadlock
> >>>>>>>> in a
> >>>>>>>> body of code.
> >>>>>>>>
> >>>>>>>> Attached is an example of the workshop.  You can try find the
> >>>>>>>> deadlock if you like.  I've shown it to almost 100 good Java
> >>>>>>>> developers and
> >>>>>>>> so far, not one has found it by themselves.  I would expect that
> >>>>>>>> they should
> >>>>>>>> find it in 5 minutes.  In our workshop they would obviously be
> >>>>>>>> helped a bit
> >>>>>>>> with hints, so that they can walk away with a good experience.
>  Use
> >>>>>>>> anything
> >>>>>>>> you like.  Oscilloscope, jstack, jconsole, whatever you like.
>  Only
> >>>>>>>> rule for
> >>>>>>>> you guys on the "concurrency-interest" list is: you can only look
> at
> >>>>>>>> the
> >>>>>>>> code once you've found the problem, otherwise it would be too easy
> >>>>>>>> for you
> >>>>>>>> :-)  Once you have found it, you can also fix the code and make
> sure
> >>>>>>>> that
> >>>>>>>> the code then works correctly.
> >>>>>>>> Regards
> >>>>>>>>
> >>>>>>>> Heinz
> >>>>>>>> --
> >>>>>>>> Dr Heinz M. Kabutz (PhD CompSci)
> >>>>>>>> Author of "The Java(tm) Specialists' Newsletter"
> >>>>>>>> Sun Java Champion
> >>>>>>>> IEEE Certified Software Development Professional
> >>>>>>>> http://www.javaspecialists.eu
> >>>>>>>> Tel: +30 69 75 595 262
> >>>>>>>> Skype: kabutz
> >>>>>>>>
> >>>>>>>> On 4/5/12 8:01 PM, Nathan Reynolds wrote:
> >>>>>>>>>
> >>>>>>>>> I am curious as to the intended content of your presentation.
> >>>>>>>>>  Here's some ideas.  I wondering what you are planing on doing.
> >>>>>>>>>
> >>>>>>>>>  1. Printing the call stacks with lock information using a tool
> >>>>>>>>>    such as jstack
> >>>>>>>>>  2. Press the "Detect Deadlock" button in JConsole
> >>>>>>>>>  3. Dealing with Lock and Condition objects instead of
> >>>>>>>>>    synchronized blocks
> >>>>>>>>>  4. Detecting live lock
> >>>>>>>>>  5. Distributed deadlocks
> >>>>>>>>>
> >>>>>>>>> Nathan Reynolds
> >>>>>>>>> <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
> >>>>>>>>> Consulting
> >>>>>>>>> Member of Technical Staff | 602.333.9091
> >>>>>>>>> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server
> >>>>>>>>> Technology
> >>>>>>>>>
> >>>>>>>>> On 4/5/2012 7:57 AM, Dr Heinz M. Kabutz wrote:
> >>>>>>>>>>
> >>>>>>>>>> Good afternoon,
> >>>>>>>>>>
> >>>>>>>>>> I am thinking of submitting a talk on finding and diagnosing
> >>>>>>>>>> deadlocks for JavaOne.  It might be a workshop, instead of a
> >>>>>>>>>> simple
> >>>>>>>>>> conference talk.  Or we might be able to turn the talk into a
> >>>>>>>>>> workshop where
> >>>>>>>>>> they need to find a deadlock in a body of code.  Could be
> >>>>>>>>>> something
> >>>>>>>>>> different, which might go incredibly well or crash in a blaze of
> >>>>>>>>>> flames.
> >>>>>>>>>>  Would any of you be interested in co-presenting this with me at
> >>>>>>>>>> JavaOne?
> >>>>>>>>>>
> >>>>>>>>>> Regards
> >>>>>>>>>>
> >>>>>>>>>> Heinz
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Concurrency-interest mailing list
> >>>> Concurrency-interest at cs.oswego.edu
> >>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>>
> >>>
> >>> _______________________________________________
> >>> Concurrency-interest mailing list
> >>> Concurrency-interest at cs.oswego.edu
> >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>>
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> Concurrency-interest at cs.oswego.edu
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120409/49733350/attachment-0001.html>


More information about the Concurrency-interest mailing list