In theory, we can get rid of the NMTPreInit handling if we break Arguments::parse into two phases in Threads::create_vm.

The first phase would happen immediately in Threads::create_vm and would use raw malloc, realloc, and free. This is okay as all allocated memory would be free'ed upon returning from Threads::create_vm so it would have no impact on NMT if it were active. The first phase would perform preflight processing by expanding and merging the user supplied JavaVMInitArgs with -XX:Flags, -XX:VMOptionsFile, _JAVA_OPTIONS, and JAVA_TOOL_OPTIONS. The first phase, while doing so, would look for the winning -XX:NativeMemoryTracking and initialize NMT before returning. In the event that Threads::create_vm is called again due to a failed attempt, the first phase would ensure that the effective NMT tracking level is the same or it would return an unretryable error.

The second phase would be where Arguments::parse is today in Threads::create_vm and would actually parse the options returned by preprocessing.

This would remove the need for NMTPreInit, thus removing the extra overhead from os::malloc, os::realloc, and os::free.