java.nio.BufferPoolMXBean getObjectName() occasionally returns null

[Steve Poole]

On 19/07/11 05:09, Alan Bateman wrote:
> (cc'ing serviceability-dev)
>
> Thanks Steve, looks like this crept as part of some refactoring work 
> [1]. Looks like PlatformLoggingMXBean has the same issue. I've created 
> the following bug to track it:
>
> 7068328: BufferPoolMXBean and PlatformLoggingMXBean getObjectName may 
> return null
>
> If no one take it in the next few days then I can take it and get it 
> push to jdk8 (listing you are contributer). The test will need a bit 
> of clean-up, re-formatting, and throwing an exception rather than 
> calling System.exit for example.
>
Thanks Alan.  I wasn't sure of the testcase form to use for a 
multithreaded problem - I will be curious to see how it ends up.
> -Alan
>
> [1] http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/77dd50ba670b
>
>
>
> -------- Original Message --------
> Subject: 	java.nio.BufferPoolMXBean getObjectName() occasionally 
> returns null
> Date: 	Mon, 18 Jul 2011 22:54:35 +0100
> From: 	Steve Poole <spoole at linux.vnet.ibm.com>
> To: 	nio-dev at openjdk.java.net
>
>
>
> Hi all,  a small fix to a race condition that occurs under extreme and
> probably unrepresentative loading...
>
> sun.management.ManagementFactoryHelper provides the default
> implementation of java.nio.BufferPoolMXBean. The  getObjectName() method
> uses a volatile field to store the object name. The name is filled in
> using a lazy sync method. Under high load a timing window is exposed in
> which the lazy sync succeeds but a caller still recieves null.
>
> The failing code is question is in
> src/share/classes/sun/management/ManagementFactoryHelper.java
>
> The diff and testcase are attached.
>
> I don't know if the testcase is the right form - it creates a bunch of
> threads that drive the method to expose the problem and is fairly
> quick.   I can show it happening on Ubuntu with JDK7 and with my local
> build of JDK8.
>
> Cheers
>
> Steve
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20110719/ce3eb9a9/attachment.html