changeset 9981:f60f6d307283

Break up large system initialization comment into smaller comments ahead of its respective call_initPhase# method.
author lfoltan
date Tue, 22 Dec 2015 14:29:58 -0500
parents 44007466d81e
children 34ce2d3ebd40
files src/share/vm/runtime/thread.cpp
diffstat 1 files changed, 33 insertions(+), 33 deletions(-) [+]
line wrap: on
line diff
--- a/src/share/vm/runtime/thread.cpp	Tue Dec 22 10:56:45 2015 -0500
+++ b/src/share/vm/runtime/thread.cpp	Tue Dec 22 14:29:58 2015 -0500
@@ -3279,6 +3279,17 @@
   // If CompilerThreads ever become non-JavaThreads, add them here
 }
 
+// The system initialization in the library has three phases.
+//
+// Phase 1: java.lang.System class initialization
+//     java.lang.System is a primordial class loaded and initialized
+//     by the VM early during startup.  java.lang.System.<clinit>
+//     only does registerNatives and keeps the rest of the class
+//     initialization work later until thread initialization completes.
+//
+//     System.initPhase1 initializes the system properties, the static
+//     fields in, out, and err. Set up java signal handlers, OS-specific
+//     system settings, and thread group of the main thread.
 static void call_initPhase1(TRAPS) {
   Klass* k =  SystemDictionary::resolve_or_fail(vmSymbols::java_lang_System(), true, CHECK);
   instanceKlassHandle klass (THREAD, k);
@@ -3288,6 +3299,17 @@
                                          vmSymbols::void_method_signature(), CHECK);
 }
 
+// Phase 2. Module system initialization
+//     This will initialize the module system.  Only java.base classes
+//     can be loaded until phase 2 completes.
+//
+//     Call System.initPhase2 after the compiler initialization and jsr292
+//     classes get initialized because module initialization runs a lot of java
+//     code, that for performance reasons, should be compiled.  Also, this will
+//     enable the startup code to use lambda and other language features in this
+//     phase and onward.
+//
+//     After phase 2, The VM will begin search classes from -Xbootclasspath/a.
 static void call_initPhase2(TRAPS) {
   Klass* k = SystemDictionary::resolve_or_fail(vmSymbols::java_lang_System(), true, CHECK);
   instanceKlassHandle klass (THREAD, k);
@@ -3298,6 +3320,12 @@
   universe_post_module_init();
 }
 
+// Phase 3. final setup - set security manager, system class loader and TCCL
+//
+//     This will instantiate and set the security manager, set the system class
+//     loader as well as the thread context class loader.  The security manager
+//     and system class loader may be a custom class loaded from -Xbootclasspath/a,
+//     other modules or the application's classpath.
 static void call_initPhase3(TRAPS) {
   Klass* k = SystemDictionary::resolve_or_fail(vmSymbols::java_lang_System(), true, CHECK);
   instanceKlassHandle klass (THREAD, k);
@@ -3340,6 +3368,8 @@
   // The VM preresolves methods to these classes. Make sure that they get initialized
   initialize_class(vmSymbols::java_lang_reflect_Method(), CHECK);
   initialize_class(vmSymbols::java_lang_ref_Finalizer(), CHECK);
+
+  // Phase 1 of the system initialization in the library, java.lang.System class initialization
   call_initPhase1(CHECK);
 
   // get the Java runtime name after java.lang.System is initialized
@@ -3642,38 +3672,8 @@
   // (see SystemDictionary::find_method_handle_intrinsic).
   initialize_jsr292_core_classes(CHECK_JNI_ERR);
 
-  // The system initialization in the library has three phases
-  // Phase 1: java.lang.System class initialization
-  //     java.lang.System is a primordial class loaded and initialized
-  //     by the VM early during startup.  java.lang.System.<clinit>
-  //     only does registerNatives and keep the rest of the class
-  //     initialization work later until thread initialization completes.
-  //
-  //     System.initPhase1 initializes the system properties, the static
-  //     fields in, out, and err. Setup java signal handlers, OS-specific
-  //     system settings, and set thread group of the main thread.
-  //
-  //     see initialize_java_lang_classes
-  //
-  // Phase 2. Module system initialization
-  //     This will initialize the module system.  Only java.base classes
-  //     can be loaded until phase 2 completes.
-  //
-  //     Call System.initPhase2 after the compiler initialization and jsr292
-  //     classes get initialized because module initialization runs a lot of java
-  //     code, that for performance reasons, should be compiled.  Also, this will
-  //     enable the startup code to use lambda and other language features in this
-  //     phase and onward.
-  //
-  //     After phase 2, The VM will begin search classes from -Xbootclasspath/a.
-  //
-  // Phase 3. final setup - set security manager, system class loader and TCCL
-  //
-  //     This will instantiate and set the security manager, set the system class
-  //     loader as well as the thread context class loader.  The security manager
-  //     and system class loader may be a custom class loaded from -Xbootclasspath/a,
-  //     other modules or the application's classpath.
-
+  // This will initialize the module system.  Only java.base classes can be
+  // loaded until phase 2 completes
   call_initPhase2(CHECK_JNI_ERR);
 
   // Always call even when there are not JVMTI environments yet, since environments
@@ -3683,7 +3683,7 @@
   // Notify JVMTI agents that VM has started (JNI is up) - nop if no agents.
   JvmtiExport::post_vm_start();
 
-  // Final system initialization including security manager and system class loader.
+  // Final system initialization including security manager and system class loader
   call_initPhase3(CHECK_JNI_ERR);
 
   // cache the system class loader