To understand and discuss on the requirement of the environment variable for command line startup of profiler, work on a solution to remove the need of them to ease the usability of the profiler. This is an area that user is having problem to setup a profiling session on machines with limitation on setup privilege.
226572 Remove requirement on environment variables setup
227779 Linux: Attempt to record fails with message that attempt to write serviceconfig.xml failed.
Minutes
Go through each of the environment variable requirement:
1. TPTP_AC_HOME
it is used by Agent to locate the serviceconfig.xml file for the following values:
a. logging level
info is the default, value is mostly changed for debug and support purpose.
Suggestion: how about an optional variable and honor only when available for debug and support purpose?
b. shared memory for data channels and name pipes values.
values are not changeable by any UI unless user manually change the serviceconfig.xml.
we do not see any need to change this value in the current setup and in long term.
can we assume the default value always? Yes.
Summary: Remove TPTP_AC_HOME and introduce an optional TPTP_AC_CONFIG_HOME for debug/support purpose and point to the new configuration location ie. workspace (see 227779). TPTP_AC_CONFIG_HOME is honor when available, default value otherwise.
AI: Eugene to contact Igor to confirm the usage of the variable and make sure there is nothing missing here on the usage of the TPTP_AC_HOME
AI: Eugene to create sub defect (241982), Talk with Chris and Joanna for resource.
2. JAVA_PROFILER_HOME
History: to allow us to use multiple Martini runtimes on the same machine.
History: jpibootloader: a thin loader to read the variable and locate the martini runtime.
This dependency can be removed as all required libraries are located under the same directory.
To make sure we are backward compatible, make this variable an optional variable and honor if it exists on the machine. Assume same libraries under same folder otherwise.
Asaf: estimate effort: easy, 1 day.
Summary: make this an optional variable and honor if exists.
AI: Eugene to create sub defect (241984), and talk to Chirs and Joanna for resource.
3. PATH/LD_LIBRARY_PATH
They must point to JPIBootLoader and AC/bin for JPIBootLoader, ACCollector and AC libraries to load.
Main reason was to streamline the standalone and command line variables.
JPIBootLoader statically load other dll and their dependencies on the system path.
To load the ACCollector and it use AC sdk and lib files to link with AC dlls.
baseAgent.dll and tptputil.dll, they need to be in system path for the OS to load.
perhaps locate and load the AC dll dynamically instead of statically.
Can we use "-agentpath" to pass a fully qualify JPIBootLoader.dll for JVM? yes, but only when server=standalone
For server=enabled/controlled, it loads ACCollector and its dependencies that require OS to load with PATH value.
If ACCollector and its dependencies are dynamically lookup in JPIBootLoader there is no need for PATH value to include them i.e AC/bin folder
"-agentpath" vm argument can then be used on local profile to locate JPIBootLoader without the need of a PATH value.
For remote profile on server use case, we still need PATH setup on remote machine because client does not have remote AC location, but PATH now only points to jvmti.runtime/javaprofiler folder and no more AC/bin is required for AC sdk and libraries loading.
Standalone should work find with the propose changes. ie. no variables is needed to setup if agentpath is used.
Summary: update JPIBootLoader to locate and load ACCollector and AC libraries dynamically.
