[concurrency-interest] Joint Talk for JavaOne?

Nathan Reynolds nathan.reynolds at oracle.com
Thu Apr 5 16:30:33 EDT 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120405/b13da5d1/attachment-0001.html>


More information about the Concurrency-interest mailing list