File system contention in debug print via XPathFactory.newInstance

FULL PRODUCT VERSION :
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Specifically encountered on Windows 6.1.6701, but affects all OSes

A DESCRIPTION OF THE PROBLEM :
I ran XPathFactory.newInstance(String, String, ClassLoader) and noticed heavy locking on the filesystem due to classloader activity. The problem appears to be in XPathFactoryFinder (line 293 in jdk8u20 / line 312 in jdk7u51):

        debugPrintln("loaded " + className + " from " + which(clazz));

The seemingly innocuous call, which(clazz), occurs even though debugging is disabled and results in unnecessary I/O and contention. A simple solution would be to wrap the call to debugPrintln in an if (debug) block. Here is a stack trace of the problem in jdk7u51, which will be very similar in jdk8u20:

   java.lang.Thread.State: BLOCKED (on object monitor)
at java.util.zip.ZipFile.getEntry(ZipFile.java:304)
- waiting to lock <0x0000000780e67928> (a java.util.jar.JarFile)
at java.util.jar.JarFile.getEntry(JarFile.java:226)
at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840)
at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:818)
at sun.misc.URLClassPath.findResource(URLClassPath.java:176)
at java.net.URLClassLoader$2.run(URLClassLoader.java:551)
at java.net.URLClassLoader$2.run(URLClassLoader.java:549)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findResource(URLClassLoader.java:548)
at java.lang.ClassLoader.getResource(ClassLoader.java:1147)
at javax.xml.xpath.SecuritySupport$5.run(SecuritySupport.java:106)
at java.security.AccessController.doPrivileged(Native Method)
at javax.xml.xpath.SecuritySupport.getResourceAsURL(SecuritySupport.java:99)
at javax.xml.xpath.XPathFactoryFinder.which(XPathFactoryFinder.java:549)
at javax.xml.xpath.XPathFactoryFinder.which(XPathFactoryFinder.java:531)
at javax.xml.xpath.XPathFactoryFinder.createInstance(XPathFactoryFinder.java:296)
at javax.xml.xpath.XPathFactoryFinder.createInstance(XPathFactoryFinder.java:283)
at javax.xml.xpath.XPathFactory.newInstance(XPathFactory.java:260)


ADDITIONAL REGRESSION INFORMATION:
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Start multiple threads that repeatedly do this:

XPath xpath = XPathFactory.newInstance(XPathFactory.DEFAULT_OBJECT_MODEL_URI, "org.apache.xpath.jaxp.XPathFactoryImpl", null).newXPath();

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No I/O or blocking between threads calling XPathFactory.newInstance with debug disabled.
ACTUAL -
I/O and blocking between threads calling XPathFactory.newInstance with debug disabled.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
XPath xpath = XPathFactory.newInstance(XPathFactory.DEFAULT_OBJECT_MODEL_URI, "org.apache.xpath.jaxp.XPathFactoryImpl", null).newXPath();
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
XPath xpath = new org.apache.xpath.jaxp.XPathFactoryImpl().newXPath();