In working with the qtrace utility to track down startup bottlenecks, I
ran a simple test that exited as soon as main() was entered. I then
looked at the data from this run in qtrace and found that nearly
half of the time running the application was going into initialization
the nio system.
In particular:
- The app took about 485 ms to complete (this is qtrace-time, not real-time.
in reality, the app takes about 300 ms to run).
- System.initializeSystemClass took about 278 ms (of the original 485 ms)
- java.io.PrintStream.<init> took about 237 ms of that 278 ms
- sun.nio.cs.StreamEncoder.forOutputStreamWriter took about 234 of that 237 ms
- java.nio.charset.Charset.<clinit> took about 198 of that 234 ms
- sun.nio.cs.StandardCharsets.<init> took about 196 of that 198 ms, which was
pretty equally distributed between various calls to AbstractCharsetProvider.charset(...).
At 234 ms out of 485 total ms, it looks like nio initialization is currently responsible for nearly half of the time spent starting the VM.
Is there anything we can do to either minimize the work done, or do it
differently, or do it lazily, such that we do not incur this one huge chunk at the startup of every app?
Details:
- I haven't attached an app because it's as simple as
public static void main(...) {
System.exit(0);
}
- The tests were run on a recent build of the java2d workspace (july 22). This
was not a promoted build, but was fairly in-sync at that time.
- The tests were run on my Windows2000 laptop system (800 MHz). I did
not run the same tests on Solaris or Linux (yet).
ran a simple test that exited as soon as main() was entered. I then
looked at the data from this run in qtrace and found that nearly
half of the time running the application was going into initialization
the nio system.
In particular:
- The app took about 485 ms to complete (this is qtrace-time, not real-time.
in reality, the app takes about 300 ms to run).
- System.initializeSystemClass took about 278 ms (of the original 485 ms)
- java.io.PrintStream.<init> took about 237 ms of that 278 ms
- sun.nio.cs.StreamEncoder.forOutputStreamWriter took about 234 of that 237 ms
- java.nio.charset.Charset.<clinit> took about 198 of that 234 ms
- sun.nio.cs.StandardCharsets.<init> took about 196 of that 198 ms, which was
pretty equally distributed between various calls to AbstractCharsetProvider.charset(...).
At 234 ms out of 485 total ms, it looks like nio initialization is currently responsible for nearly half of the time spent starting the VM.
Is there anything we can do to either minimize the work done, or do it
differently, or do it lazily, such that we do not incur this one huge chunk at the startup of every app?
Details:
- I haven't attached an app because it's as simple as
public static void main(...) {
System.exit(0);
}
- The tests were run on a recent build of the java2d workspace (july 22). This
was not a promoted build, but was fairly in-sync at that time.
- The tests were run on my Windows2000 laptop system (800 MHz). I did
not run the same tests on Solaris or Linux (yet).
- relates to
-
JDK-5021956 Many extended charsets have no aliases
-
- Resolved
-