RFR: 8340114: Remove outdated SelectVersion() function from the launcher and update the code comments explaining the code flow [v6]

[David Holmes]

On Mon, 16 Sep 2024 14:02:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> In the context of the 2 platforms - macosx and unix, the recursive invocation still continues to happen.
>> 
>> For macosx, the `CreateExecutionEnvironment` unconditionally, through an internal `MacOSXStartup` function, spawns a new thread (`pthread_create`). That thread is passed a function pointer pointing to the current executable/process' `main(...)` function (and thus made to execute afresh). That then triggers this recursion where `JLI_Launch` is called again and that then calls into `CreateExecutionEnvironment` all the way to `MacOSXStartup` function which has the necessary knowledge not to spawn another thread the second time.
>> 
>> For unix, in the `CreateExecutionEnvironment` function, there's a specific piece of code which determines whether or not `LD_LIBRARY_PATH` environment variable needs to be set or updated before loading the JVM. This decision of whether or not `LD_LIBRARY_PATH` needs to be updated or set is done in an internal function called `RequiresSetenv`. There are several rules which determine whether or not to set/update that environment variable. Rules like - is musl libc in use; or is the runtime environment AIX; or if the `LD_LIBRARY_PATH` is currently set, then whether the value in the environment variable matches some well known JVM library path patterns (like `lib/client`, `lib/server`). If any of these rules determine that the `LD_LIBRARY_PATH` needs to be set/updated, then the `CreateExecutionEnvironment` function will do the necessary updates to the environment variable value and and exec() the current process with that new value. This then triggers the recursion all the way from th
 e `JLI_Launch` back into this `CreateExecutionEnvironment` (which has the necessary knowledge not to exec() once more).
>
>> For macosx, the CreateExecutionEnvironment unconditionally, through an internal MacOSXStartup function, spawns a new thread (pthread_create).
> 
> I forgot to note that, the reason for spawning this new thread is explained as a code comment (unrelated to the changes in this PR) on the `MacOSXStartup` function and it says:
> 
> 
> /*
> * Mac OS X mandates that the GUI event loop run on very first thread of
> * an application. This requires that we re-call Java's main() on a new
> * thread, reserving the 'main' thread for Cocoa.
> */

That aside, the launcher always tries to spawn a new thread because bad stuff can happen on some OS if we try to make the process primordial thread a JavaThread (e.g. you can't enforce stack size limits).

But I remain unclear as to why the new thread has to "start again" rather than continuing with the launch process- it is even called ContinueInNewThread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20997#discussion_r1762683203