JDK-8223260 : NamingManager should cache InitialContextFactory
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: 11.0.4
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-05-02
  • Updated: 2020-06-09
  • Resolved: 2020-02-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 15
11.0.7-oracleFixed 13.0.4Fixed 15 b10Fixed
Related Reports
Relates :  
JDK-8230297 - Slow LoginContext.login() due to repeated ServiceLoader lookups
Relates :  
JDK-8238688 - Clarify spec for NamingManager.getInitialContext(Hashtable)
Description
Submitter running a stress scenario  - 
MegaJSP against JDK8u201 build and JDK11 build to compare the performance. With JDK8 we are observing a better performance when compared to the run with JDK11 and the performance drop that is observed is around 8%.
Comments
Fix request (13u) Requesting backport to 13u for parity with 11u, applies cleanly but needs adjustments. RFR: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003268.html
09-06-2020
Fix Request (OpenJDK 11u): Please approve backporting this to OpenJDK 11u. This is an Oracle JDK 11 feature parity patch. The patch applies cleanly but the result didn't build, so I've done a webrev and got it reviewed by Goetz Lindemaier. Testing tier 1 and javax/naming tests (including new regression test). Passed. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8223260/01/webrev/ RFR: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002616.html
27-02-2020
fix included in CPU20_04 - no BPR needed
14-02-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/92b01977fde2 User: coffeys Date: 2020-02-10 07:19:12 +0000
10-02-2020
Given that the diagnostic output seems too verbose/slow, we need to consider alternative routes. Looking at the JFR 11 recordings, I notice that the JarFile locking mainly stems from threads involving the initialization of megaJSP.ShoppingCartBean. Each such initialization appears to involve a search for the InitialContext to be used with NamingManager. This algorithm was enhanced in JDK 11 to use the ServiceProvider. I think we can help tweak code in the JDK libraries side also. Perhaps maintain a `WeakHashMap<ClassLoader, InitialContextFactory>` cache - The fast path scenario should return the same Factory and avoid the ServiceLoader lookup code which can be costly in the case of slow I/O and/or many delegating classloaders.
27-01-2020
Submitter also highlighting a lock that seems to have some contention on it. From my JFR analysis, I see threads blocked for 60ms - it might be acceptable ? The corresponding stack trace: ZipEntry java.util.zip.ZipFile.getEntry(String, Function) 9 JarEntry java.util.zip.ZipFile$1.getEntry(ZipFile, String, Function) 9 JarFile$JarFileEntry java.util.jar.JarFile.getEntry0(String) 9 ZipEntry java.util.jar.JarFile.getEntry(String) 9 JarEntry java.util.jar.JarFile.getJarEntry(String) 9 JarEntry com.oracle.classloader.JarCodeSource.getJarEntry(String) 8 URL com.oracle.classloader.JarCodeSource.getResource(String) 8 This JarFile lock was from a re-design of code in JDK 9 and on the whole should have better performance. I've delivered test instrumented JDK binaries to submitter in order to gather more data from their 8u and 11u reproducers. Awaiting that data.
16-05-2019