Qbicc Initialization Steps
David Grove edited this page Jan 5, 2022
·
8 revisions
BT? | RT? | Description | initLevel | OpenJDK Location | Qbicc Location | OS |
---|---|---|---|---|---|---|
Y | Initialize processor count, page size, etc. | 0 | os::init_before_ergo | All | ||
Y | OS-specific native thread library and signal intialization | 0 | os::init_2 | Linux,Windows,Posix,... | ||
Y | Attach the Java main thread to the main os thread | 0 | Threads::create_vm | All | ||
Y | Initialize core Java classes | 0 | Threads::initialize_java_lang_classes | VmImpl.initialize | All | |
Y | setJavaLangAccess | 0 | System.initPhase1 | All | ||
Y | SystemProps.initProperties | 0 | System.initPhase1 | All | ||
Y | System.createProperties | 0 | System.initPhase1 | All | ||
Y | Y | Initialize stdin, stdout, stderr | 0 | System.initPhase1 | All | |
Y | Terminator.setup | 0 | System.initPhase1 | All | ||
Y | VM.initializeOSEnvironment | 0 | System.initPhase1 | No-op except on Windows | ||
Y | add MainThread to ThreadGroup | 0 | System.initPhase1 | All | ||
Y | Lots of HotSpot native initialization we can probably ignore, but needs to be checked to be sure | 1 | Threads::create_vm | |||
Y | Initialize JSR292 core classes | 1 | Threads::initialize_jsr292_core_classes | VmImpl.initialize? | All | |
Y | ModuleBootstrap.boot() | 1 | System.initPhase2 | All | ||
Y | Initialize SecurityManager | 2 | System.initPhase2 | All | ||
Y | Initialize System ClassLoader | 3 | System.initPhase3 | All | ||
Y | Initialize ThreadContextClassLoader | 3 | System.initPhase3 | All | ||
Y | Run post-VM startup hooks | 4 | Threads::create_vm | All |
Some general patterns to deal with:
- methods that create/start service Threads, for example like
java.lang.ref.Reference
. We at least need to defer theThread.start()
to runtime, even if we chose to optimize application startup by instantiating the Threads at build time. - Serializing hash-based data structures which have used the default hashcode value computed by the build-time VM.
- Objects in the build-time heap that refer to native resources (eg file descriptors). We need to somehow invalidate these and/or guide the user to provide runtime initialization annotations that defer their creation to application runtime.
Other things that happen in OpenJDK/HotSpot startup that we might need to support
- JVMTI and other agents
- Signal handler registration
- Baroque interactions between command line arguments and system properties
- JNI initialization
- Management support