RFR: 8313562: hsperfdata should export module path and "launcher" metadata

[David Holmes]

On Mon, 20 May 2024 18:09:10 GMT, Larry Cable <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/statSampler.cpp line 266:
>> 
>>> 264:   add_property_constant(JAVA_PROPERTY, "jdk.module.path", CHECK);
>>> 265:   add_property_constant(JAVA_PROPERTY, "jdk.module.upgrade.path", CHECK);
>>> 266:   add_property_constant(JAVA_PROPERTY, "jdk.module.main", CHECK);
>> 
>> These are not "java" properties - do we need to add a "jdk" namespace?
>
> correct @dholmes-ora however a couple of points to note:
> 
> - these properties *are* listed in the javadoc for System::getProperties also "jdk.debug" is a pre-existing property also present in the JAVA_PROPERTY NS ... which somewhat sets an awkward precedent...
> 
> happy to add a new JDK_PROPERTY NS but given the pre-existence of "jdk.debug" not clear to me that such would not introduce an arbitrary inconsistency
> 
> thoughts?

I'm not sure what the list of system properties in `System.get_properties` has to do with this. That list includes a bunch of properties in the `java` namespace and a bunch not.

The pre-existence of jdk.debug is unfortunate and, I think, a mistake. As you can see from the JBS issue description the original intent was to have java.vm.debug but it got changed to jdk.debug:

https://bugs.openjdk.org/browse/JDK-8139986

I think the question that needs to be answered is why do these different namespaces even exist? AFAICT the SUN_* namespace is used for internal/implementation things and arguably if we could have we might have renamed that to JDK_*. But the reality is that we are dealing with an archaic part of the system that really reflects an age long past and could do with some modernization.

So I guess for the sake of moving forward we can ignore the namespace for now and just flag these as "Java" properties.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19287#discussion_r1607535029