JDK-8042469 : Launcher changes for native memory tracking scalability enhancement
  • Type: Enhancement
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-05-06
  • Updated: 2021-08-01
  • Resolved: 2014-08-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u40Fixed 9 b26Fixed
Related Reports
Blocks :  
JDK-8028541 - Native Memory Tracking enhancement
Blocks :  
JDK-8046598 - Scalable Native Memory Tracking development
Relates :  
JDK-8028541 - Native Memory Tracking enhancement
Relates :  
JDK-8256844 - Make NMT late-initializable
Description
Native memory tracking scalability enhancement project requires the tracking system to determine tracking level before the first malloc call from inside JVM, ahead of JVM command line argument processing code.

The solution purposed here, is to have launcher pre-parsing native memory tracking command line option and setup a private environment variable.

Native memory tracking system inside JVM uses this private environment variable to determine the tracking level and unset it if it presents.
Comments
The JVM changes must go in at the same time since it is the consumer of the environmental variable created by this launcher patch
30-07-2014
webrev-08 patch reviewed and accepted. It was tried by Zhengyu this morning and works. Archived here for putback barring any additional changes to jvm.
02-07-2014
As a note, Zhengyu decided to tighten up the wording to remove ambiguity. The CCC has been resubmitted and okayed. The current CCC states that the launcher will pass the argument along to the JVM unaltered.
20-06-2014
We will keep the option to allow launcher to discard CLI, as CCC request stated.
12-06-2014
Several notes in implementation since a prototype was submitted. 1) prototype using SetEnvironmentalVariable() for Win replaced with _putenv() The launcher in the shared code uses getenv(). getenv() reads from static data. For this reason the launcher must use setenv() or putenv() to create a new environmental variable for itself or its children. The static data is then updated. Apparently, as show in tests, SetEnvironmentalVariable() does not update this static data, though it does set the environmental var. So reading the env right after writing it using: SetEnvironmentalVariable() getenv() will result in getenv() returning null on windows. setenv() is not available on windows, but putenv() and _putenv() are on NIXES and windows respectively. 2) getenv() . On Oracle Linux for env variable MYENV= !!! Returns "" undefined MYENV !!! Returns null . On Windows MYENV= !!! Returns null undefined MYENV !!! Returns null ! Just a note on the slight variation between Windows and NIXES for getenv(). === TESTING Scenarios === TestCmd : $JDK9BIN/java -XX:NativeMemoryTracking helloworld Expected: Error occurred during initialization of VM Syntax error, expecting -XX:NativeMemoryTracking=[off|summary|detail] TestCmd : $JDK9BIN/java -XX:NativeMemoryTracking= helloworld Expected: Error occurred during initialization of VM Syntax error, expecting -XX:NativeMemoryTracking=[off|summary|detail] The following will be used to make sure the launcher is setting the environmental variable correctly. As mentioned in previous comments, the JVM validates the argument and value supplied. With Env Varaible: _JAVA_LAUNCHER_DEBUG=TRUE TestCmd :$JDK9BIN/java -XX:NativeMemoryTracking=blahblah helloworld Expected: NOTE: if "blahblah" is value, get "NativeMemoryTracking: got value blahblah" NativeMemoryTracking: NMT_LEVEL_ NativeMemoryTracking: env var is NMT_LEVEL_5232 NativeMemoryTracking: putenv arg NMT_LEVEL_5232=blahblah NativeMemoryTracking: set value blahblah NativeMemoryTracking : return value from JLI_PutEnv = 0 NativeMemoryTracking: got value blahblah
12-06-2014
The CCC was found to be incorrect today with respect to how launcher deals with the Native Memory Tracking parameter. The CCC text says: ----- In order to do so, the JVM must initialize the NMT mechanism even before the JVMs command line parser can be called. In order to mitigate this, the launcher must intercept the option and an environment variable must be set, thereafter the launcher is free to discard the CLI option. The JVM will remove the environment variable once it is consumed, such that the env variable will not be inherited or exposed to any spawned sub-processes. ----- Zhengyu will change the CCC removing "thereafter the launcher is free to discard the CLI option.". The launcher will pass this parameter to the JVM for processing after creating the environmental variable if required.
12-06-2014
The launcher support for the JVM's Native Memory Tracking changes entails correctly identifying the relevant parameter and setting an environmental variable if needed. A test will be added to make sure that the environmental variable has the correct name, including the current launcher PID, and that the value was set. As the CCC notes, the JVM will validate the value supplied with the parameter.
09-06-2014
There is a patch available with suggestion for changes. But the implementer of this RFE would still need to write tests.
06-05-2014