Hi Daniil,
I'm confused with the change: for (int i = 1; i < parts.length && mainClass == null; i++) { if (i < parts.length - 1) { if (parts[i].equals("-m") || parts[i].equals("--module") || parts[i].equals("-jar")) { <= ?????? return parts[i + 1]; } } - // If this is a classpath or a module path option then skip the next part - // (the classpath or the module path itself) + + if ((parts[i].startsWith("--module="))) { <= ?????? + return parts[i].substring("--module=".length()); + } + + // If this is a classpath or a module whitespace option then skip the next part + // (the classpath or the option value itself) if (parts[i].equals("-cp") || parts[i].equals("-classpath") || parts[i].equals("--class-path") || - parts[i].equals("-p") || parts[i].equals("--module-path")) { + isModuleWhiteSpaceOption(parts[i])) { . . . + private static boolean isModuleWhiteSpaceOption(String option) { + return option.equals("-p") || + option.equals("--module-path") || How these changes are going to work for options "--module=" and "--module-path" if there is this check at the beginning of each iteration: parts[i].equals("--module") ? Also, this line has unneeded extra "()": + if ((parts[i].startsWith("--module="))) {
Thanks, Serguei On 6/12/19 10:50, Daniil Titov wrote: Hi David and Serguei, Could you please have a look at this change? This fix is related with the changes [3] that you reviewed back in February. Mach5 sun/tools/jcmd, serviceability/dcmd/framework, jdk_svc, hotspot_serviceability, tier1, tier2 and tier3 tests passed. Thanks a lot! --Daniil On 6/10/19, 4:56 PM, "serviceability-dev on behalf of Daniil Titov" <serviceability-dev-boun...@openjdk.java.net on behalf of daniil.x.ti...@oracle.com> wrote: Please review the change that fixes jcmd process name matching on Linux platform. After changes [3] , on Linux platform the proc filesystem is used to find a Java process, however, sun.tools.ProcessHelper class, introduced in that change, didn't take into account the presence of module whitespace options ( e.g. --patch-module) or the fact that some values of Java options could contain whitespaces. The latter problem is fixed by keeping '\0' as a separator for command line arguments read from /proc/{pid}/cmdline rather than replacing it with a whitespace. The former problem is fixed by making sun.tools.ProcessHelper aware of these module whitespace options (--add-opens, --add-exports,--add-reads, --add-modules, --patch-module,--limit-modules, or --upgrade-module-path) as well as of the case when a source-file mode is used or when --module options is used in "--<name>=<value>" format. Testing: sun/tools/jcmd and serviceability/dcmd/framework tests succeeded in Mach5. jdk_svc, tier1, tier2, and tier3 tests are in progress. [1] Webrev: http://cr.openjdk.java.net/~dtitov/8225543/webrev.01/ [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8225543 [3] https://bugs.openjdk.java.net/browse/JDK-8205654 Thanks! --Daniil |
- FW: 8225543: Jcmd fails to attach to the Java p... Daniil Titov
- Re: FW: 8225543: Jcmd fails to attach to t... serguei.spit...@oracle.com
- Re: 8225543: Jcmd fails to attach to t... Daniil Titov
- Re: 8225543: Jcmd fails to attach ... serguei.spit...@oracle.com
- Re: 8225543: Jcmd fails to attach to the J... David Holmes
- Re: 8225543: Jcmd fails to attach to t... Daniil Titov