On Mon, 16 Sep 2024 14:02:21 GMT, Jaikiran Pai <j...@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
