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 <[email protected]>
To: [email protected]
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
