There are a number of predicates provided for determining how far along the initialization of the VM has reached. There are at least the following (in order of becoming true?):

- Universe::is_fully_initialized()
- is_init_completed()
- Threads::is_vm_complete()

and also
- Universe::is_bootstrapping()

The intended meaning for these is largely undocumented, and the actual meaning based on behavior and usage is often unclear, with some uses appearing to be inconsistent with the actual behavior.

is_bootstrapping seems to have an unusual implementation, being false except during the scope of the call to Universe::genesis(). That function is only called by universe2_init(), which is called after universe_init(). So early in the VM initialization process this predicate returns false, then returns true for a period, and then reverts to false. All of the other predicates listed are initially false and are permanently set to true at the completion of some stage of initialization.

Universe::is_fully_initialized is set true by universe_init(). It appears to mean the heap is sufficiently set up to support allocation. It does not appear to indicate that garbage collection can be performed. [Surrogate locker thread has not been created for use by concurrent collectors, marksweep_init is called after universe_init.] Unfortunately, there appear to be places that are using it as such a query.

is_init_completed is expected to be true before any Java threads are created. It controls OOME handling (throw vs vm_exit_during_initialization). It does not indicate that garbage collection can be performed. [Non-concurrent collectors probably work by this time. The surrogate locker thread has not been created for use by concurrent collectors, so some collections may fail and terminate the VM; the SLT is only needed for some collections.] Unfortunately, there appear to be places that are using it as such a query. [may have additional semantics]

is_vm_complete is set at the very end of create_VM.

There isn't a specific predicate for testing whether a GC can be performed. However, there are several places that use one or another of these predicates for that purpose. Some of those uses appear to be incorrect or unnecessary.

Some examples:

ConcurrentMarkSweepThread::run() starts out with a loop that waits for both is_init_completed() and Universe::is_fully_initialized() to be true. The former being true implies the latter is true. Once those are true it then continues on and waits until the SLT has been initialized. Since the SLT is a Java thread, and so can't be created until after is_init_completed() is true, the initial wait is in fact wasted code. Note also that the comment preceding this block says "Wait untilUniverse::is_fully_initialized()".

ConcurrentGCThread::wait_for_universe_init() actually waits for is_init_completed() rather than Universe::is_fully_initialized(), the latter being the test for universe_init() having completed.

Metaspace::allocate() uses is_init_completed() to determine whether to perform a full GC. If the invoked collection ends up needing the SLT then it might be that it could fail.

There should be clearly specified semantics for each of these predicates, so that we can examine existing uses for mistakes, know when to use which predicate in the future, and know whether changes to the behavior of these predicates are correct or might affect clients.

We need to examine existing uses of these predicates for mistakes, and fix them.

It would be nice if we could eliminate one or more of these predicates, rather than continuing to accumulate them. However, it's not clear which (if any) could actually be eliminated.