JDK-8023563 : Bottleneck in java.util.TimeZone.getDefaultInAppContext
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 Availabitlity Release.
I'm closing this bug as not verified because there is no provided way to verify this.
Good point. It's 8-na. Escalated issue on jdk6 in any case. I'll fix in 7 & 6.
No - not a dup. This concerns bottleneck in unnecessary calls to AppContext. Turns out that we're using AppContext even if security manager is not installed. The assumption was that loading of AWT AppContext class would mainly be done by plugin manager. As per stacktrace, that's not the case :
@ java.lang.Exception: Stack trace
@ at java.lang.Thread.dumpStack(Thread.java:1249)
@ at sun.awt.AppContext.<clinit>(AppContext.java:798)
@ at com.sun.jmx.trace.Trace.out(Trace.java:180)
@ at com.sun.jmx.trace.Trace.isSelected(Trace.java:88)
We should only use the AppContext approach in TimeZone if security manager is present.
Bottleneck in java.util.TimeZone.getDefaultInAppContext
Several threads blocked waiting to access sun.awt.AppContext
Multithreads app making high number of calls to java.util.TimeZone.getDefault
Introduced at JDK-7110687 fix time. (Introduction of AppContext storage in
HOW TO VERIFY:
NOTES FOR SE:
REGRESSION: Performance issue.