[concurrency-interest] Joint Talk for JavaOne?

Rémi Forax forax at univ-mlv.fr
Thu Apr 5 18:51:17 EDT 2012


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



More information about the Concurrency-interest mailing list