From lkorinth at openjdk.org  Mon Sep  4 11:04:44 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 4 Sep 2023 11:04:44 GMT
Subject: jmx-dev RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

I have created an alternative that uses enums to force the user to make a decision: https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools . Another alternative is to do the same but instead using an enum (I think it is not as good). A third alternative is to use the current pull request with a better name.

What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1705068700

From rriggs at openjdk.org  Tue Sep  5 18:08:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 5 Sep 2023 18:08:39 GMT
Subject: jmx-dev RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
 <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>
Message-ID: <CZcrmy99xK8GvWF8BD1TmmM_Q8F0po6d3zExg2zNtSY=.9d126ffd-f3ad-4257-a0e4-0a83e3e17a47@github.com>

On Mon, 4 Sep 2023 11:01:23 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test ca

The current API (name) is fine and fit for purpose; it does not promise or hide extra functionality under a simple name.

There needs to be an explicit intention in the test(s) to support after the fact that arbitrary flags can be added.
@AlanBateman's proposal for naming [above](https://github.com/openjdk/jdk/pull/15452#issuecomment-1700459277) (or similar) would capture more clearly that test options are propagated to the child process.
Every test writer should be aware that additional command line options may be mixed in.

There are many cases in which the ProcessTools APIs are not used to create child processes and do not need to be used in writing tests. They provide some convenience but also add a dependency and another API layer to work through in the case of failures.

As far as I'm aware, there is no general guidance or design pattern outside of hotspot tests to propagate flags or use ProcessTools. Adding that as a requirement will need a different level of communication and change.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1707072375

From msheppar at openjdk.org  Tue Sep  5 22:25:39 2023
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 5 Sep 2023 22:25:39 GMT
Subject: jmx-dev RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <Rr1FNFUPl3iuZz7bCujdhv3jOHvKx_ruMOE-55E_xOM=.3eca3dc7-aa3b-481c-8b16-cf16363e3c51@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

> From talking to other HotSpot devs it is quite clear that the different names lead to mistakes when writing (copy-n-pasting) tests, so I'm happy that we try to figure out some way to make it more obvious when we prepend the extra test options and when we don't.
> 
> I agree with @msheppar that `createTestJvm` isn't a good name and I wouldn't be opposed to changing that name instead of `createJavaProcessBuilder`. However, if we do rename that function I strongly urge us to also rename the corresponding `executeTestJvm` function.
> 
> I also think it is too obscure that functions with _Test_ in the name prepend the extra test options, and those without _Test_ don't, so I'd like to get rid of that convention.
> 
> I wouldn't be opposed to a change that:
> 
>     * Keeps the `createJavaProcessBuilder` name
> 
>     * Renames `createTestJvm` to `createJavaProcessBuilderPrependTestOpts`
> 
>     * Renames `executeTestJvm` to `executeJavaPrependTestOpts`
> 
>     * Removes `createTestJava`
> 
>     * Removes `executeTestJava`

I think @stefank made a reasonable suggestion which was endorsed by @AlanBateman 

which would remove the misconception hurdle

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1707391042

From erikj at openjdk.org  Tue Sep  5 22:58:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 5 Sep 2023 22:58:17 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
Message-ID: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>

There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.

It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

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

Commit messages:
 - JDK-8267174

Changes: https://git.openjdk.org/jdk/pull/15573/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15573&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8267174
  Stats: 1944 lines in 648 files changed: 0 ins; 1296 del; 648 mod
  Patch: https://git.openjdk.org/jdk/pull/15573.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15573/head:pull/15573

PR: https://git.openjdk.org/jdk/pull/15573

From cjplummer at openjdk.org  Tue Sep  5 23:15:36 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 5 Sep 2023 23:15:36 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools.

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1707426607

From jjg at openjdk.org  Tue Sep  5 23:18:39 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 5 Sep 2023 23:18:39 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <ErmTPBNTxKaZzGIpFoc5zVcKasKdx5yGSmhU4mQC7SE=.55425d66-4493-4391-8b76-271e40259c05@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

One has to wonder about the `**/*_OLD.java` files, but that would be a different cleanup

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

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1612069262

From valeriep at openjdk.org  Tue Sep  5 23:37:37 2023
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 5 Sep 2023 23:37:37 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <aVRmvg-3pOxfnv6lMg93x2owljLiQwkjkEAPkLoomZg=.d714bb29-e4c4-4dd1-bb4f-21f38175294b@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Security area looks good.

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

Marked as reviewed by valeriep (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1612089791

From alanb at openjdk.org  Wed Sep  6 07:53:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Sep 2023 07:53:36 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <ErmTPBNTxKaZzGIpFoc5zVcKasKdx5yGSmhU4mQC7SE=.55425d66-4493-4391-8b76-271e40259c05@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
 <ErmTPBNTxKaZzGIpFoc5zVcKasKdx5yGSmhU4mQC7SE=.55425d66-4493-4391-8b76-271e40259c05@github.com>
Message-ID: <fOmBMZKLj2AJTcJh3JfjZbZRF_BtOusIx3tDlHq5QhE=.422d0570-2764-40ac-b224-a79c54396ece@github.com>

On Tue, 5 Sep 2023 23:15:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> One has to wonder about the `**/*_OLD.java` files, but that would be a different cleanup

The IBM double byte charsets were re-implemented in JDK 7. I think the old implementations moved to the test tree so it could be used to test the new/replacement implementations.

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1707845577

From dfuchs at openjdk.org  Wed Sep  6 11:54:38 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 6 Sep 2023 11:54:38 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <N2aDwFlX5JMFggsLteErbSyA6N4JJpAJcXSYurnNCQk=.b0556411-442f-465e-86da-705f04a63ceb@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

jmx, jndi, and net changes LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613147541

From aivanov at openjdk.org  Wed Sep  6 13:09:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Sep 2023 13:09:38 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <Nm6Ho3fcyVeur-ccqrwdrgo0N_E0YFQzHa1FnaqqVI8=.690a5255-fa88-40d1-ac4a-59b8b2b03873@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Client changes look good.

I've looked through all the files, other files look good too.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613295743

From iris at openjdk.org  Wed Sep  6 16:02:41 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 6 Sep 2023 16:02:41 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <apHME2YL4_kpuLd0FXFapVoPEswuBVLBYVzTDihni28=.3d5ef23e-2f8d-42b0-a8ef-28f43b5bcb81@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Thanks for fixing!

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1613704179

From erikj at openjdk.org  Wed Sep  6 16:09:41 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Sep 2023 16:09:41 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
 <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>
Message-ID: <COVF0o1_bFWLt5TzHHt5SBSKbJBePV9w976-mK6XfJI=.402eaef6-a008-46f8-8618-c037d5f7d3ed@github.com>

On Tue, 5 Sep 2023 23:12:51 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools.

Do you think I should revert them?

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708676439

From lkorinth at openjdk.org  Wed Sep  6 16:24:45 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 6 Sep 2023 16:24:45 GMT
Subject: jmx-dev RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
Message-ID: <cAbrAW1-EzSMgJMLOD90ZAgUNU7LcbYF3GYZKPp7sgw=.5f71207b-0641-4b7d-9033-d35e25fd90ef@github.com>

On Wed, 30 Aug 2023 09:23:55 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix static import

I think you are missing the point. If you take a look at [the parent bug of the sub task](https://bugs.openjdk.org/browse/JDK-8314823) you can see that the problem described is *not* that people are using `createTestJvm` in error. The problem is that they are (or possibly are) using `createJavaProcessBuilder` in error. Thus renaming `createTestJvm` might help a little at most for this specific problem. Renaming `createJavaProcessBuilder` most probably helps *more*. I guess the alternative of forcing the user to make a choice using an enum value will help even more.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1708705105

From cjplummer at openjdk.org  Wed Sep  6 16:52:42 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 6 Sep 2023 16:52:42 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <COVF0o1_bFWLt5TzHHt5SBSKbJBePV9w976-mK6XfJI=.402eaef6-a008-46f8-8618-c037d5f7d3ed@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
 <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>
 <COVF0o1_bFWLt5TzHHt5SBSKbJBePV9w976-mK6XfJI=.402eaef6-a008-46f8-8618-c037d5f7d3ed@github.com>
Message-ID: <AbS7Ii1Khvc-IgG5coXkZLsT65ejrEmZIDRhZd0mozs=.77261588-8a07-46d4-a4d8-b0a5b6ce481e@github.com>

On Wed, 6 Sep 2023 16:06:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools.
> 
> Do you think I should revert them?

I'm not sure. I think you need to consult someone with expertise in this area.

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708757719

From alanb at openjdk.org  Wed Sep  6 17:45:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Sep 2023 17:45:41 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <AbS7Ii1Khvc-IgG5coXkZLsT65ejrEmZIDRhZd0mozs=.77261588-8a07-46d4-a4d8-b0a5b6ce481e@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
 <alKbeUjYx-bmlIOz5W2MLc-ow-bjKAaHIqOs0-L3lwM=.39a87798-9a0a-41f4-ac0e-a1b0c683e77d@github.com>
 <COVF0o1_bFWLt5TzHHt5SBSKbJBePV9w976-mK6XfJI=.402eaef6-a008-46f8-8618-c037d5f7d3ed@github.com>
 <AbS7Ii1Khvc-IgG5coXkZLsT65ejrEmZIDRhZd0mozs=.77261588-8a07-46d4-a4d8-b0a5b6ce481e@github.com>
Message-ID: <M3p5gLpJ1VZuXjRBL3DVy6aVVpw-iAyuAJGxwWLYVcY=.40e98cad-b75c-4caa-b41f-d8bd63c5a9ba@github.com>

On Wed, 6 Sep 2023 16:49:39 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > I wonder if this is the right thing to do for the hprof files. I believe they originated from some hprof tools that we no longer ship. 3rd parties might choose to integrate them into their own tools.
> 
> Do you think I should revert them?

They are test classes now. If someone does want to copy them into their own repo then I assume they can take it from an old repo, maybe from when the "hat" tool existed.

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1708828207

From dholmes at openjdk.org  Mon Sep 11 07:15:45 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 11 Sep 2023 07:15:45 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <-l07QgwUIOOMsXw9SniuLk856xxeIs8v6lwe8SWO_oI=.7c375b23-9f35-4d0d-a7bb-5fe513edb1d5@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Looks good. I have often pointed out that the CPE was not relevant for test files but ...

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1619274864

From ihse at openjdk.org  Mon Sep 11 10:37:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Sep 2023 10:37:45 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <PgnNOjnEriF0t6VBP3CIbu8HSSLcD2FQV1HgQHOgcyc=.65e4127f-2449-4fa2-b0a1-531767e43f21@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Looks good to me. Thanks for doing this cleanup!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15573#pullrequestreview-1619669362

From erikj at openjdk.org  Tue Sep 12 20:18:51 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 20:18:51 GMT
Subject: jmx-dev RFR: 8267174: Many test files have the wrong Copyright
 header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <voTsZOBLJzcqq6sseL9fyaUN7-hcImBW9tyGILGGqSc=.d0734a02-5078-446c-b4b5-35e84fa7aedd@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

Thanks for reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/15573#issuecomment-1716362585

From erikj at openjdk.org  Tue Sep 12 20:18:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Sep 2023 20:18:52 GMT
Subject: jmx-dev Integrated: 8267174: Many test files have the wrong
 Copyright header
In-Reply-To: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
References: <eugMZvKnDktxonQdpzNzRPLODRYksBi94WijiOvtWFM=.ac7553fb-1cdf-4169-bb03-8bff5e84050c@github.com>
Message-ID: <0l5wbPPACAFDpuzCNnCNkr_RJ35CFXxPC9EpiVFt_Ao=.fbfbc877-43fd-4706-9d0d-bace4d004632@github.com>

On Tue, 5 Sep 2023 22:49:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> There are a number of files in the `test` directory that have an incorrect copyright header, which includes the "classpath" exception text. This patch removes that text from all test files that I could find it in. I did this using a combination of `sed` and `grep`. Reviewing this patch is probably easier using the raw patch file or a suitable webrev format.
> 
> It's my assumption that these headers were introduced by mistake as it's quite easy to copy the wrong template when creating new files.

This pull request has now been integrated.

Changeset: 020255a7
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/020255a72dc374ba0bdd44772047f14a8bfe69a9
Stats:     1944 lines in 648 files changed: 0 ins; 1296 del; 648 mod

8267174: Many test files have the wrong Copyright header

Reviewed-by: valeriep, aivanov, iris, dholmes, ihse

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

PR: https://git.openjdk.org/jdk/pull/15573

From jlu at openjdk.org  Tue Sep 12 22:04:12 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Sep 2023 22:04:12 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles to
 UTF-8 native
Message-ID: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>

JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.

This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.

The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)

The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.

If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

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

Commit messages:
 - Update header / copyright for CurrencyFormat
 - Adjust CurrencyFormat test to read in .properties with UTF-8
 - Convert unicode escape sequences to native
 - Add clarifying comment in Bug6204853 for lack of conversion
 - Read JDK properties files in UTF-8 during build process for LRB

Changes: https://git.openjdk.org/jdk/pull/15694/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301991
  Stats: 28966 lines in 488 files changed: 14 ins; 0 del; 28952 mod
  Patch: https://git.openjdk.org/jdk/pull/15694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694

PR: https://git.openjdk.org/jdk/pull/15694

From liach at openjdk.org  Tue Sep 12 23:16:40 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Sep 2023 23:16:40 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native
In-Reply-To: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
Message-ID: <J7d2aEX-HZ3icqioTX6_1cIVuqDXsj3oTibvKqMhpXA=.6b496c32-a89c-4ba8-86f4-5b1657f6d378@github.com>

On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
> 
> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
> 
> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
> 
> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
> 
> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 227:

> 225:         try (FileInputStream input = new FileInputStream(propertiesPath);
> 226:              // Read in JDK .properties files in UTF-8
> 227:              InputStreamReader streamReader = new InputStreamReader(input, StandardCharsets.UTF_8)

Can we just uses `Files.newBufferedReader(Path.of(propertiesPath))` instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15694#discussion_r1323716978

From jlu at openjdk.org  Wed Sep 13 17:38:28 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 17:38:28 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native [v2]
In-Reply-To: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
Message-ID: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>

> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
> 
> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
> 
> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
> 
> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
> 
> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Replace InputStreamReader with BufferedReader

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15694/files
  - new: https://git.openjdk.org/jdk/pull/15694/files/0f3698a5..ceb48bbe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15694&range=00-01

  Stats: 18 lines in 2 files changed: 6 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15694.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15694/head:pull/15694

PR: https://git.openjdk.org/jdk/pull/15694

From naoto at openjdk.org  Wed Sep 13 18:14:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Sep 2023 18:14:41 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <P4kk89ZhTNI88oojKYUPUAxLf1XgVj1Y4hL877t5uO8=.9b61c85a-d0e5-4980-ae7d-38f95a467083@github.com>

On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>> 
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>> 
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>> 
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>> 
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace InputStreamReader with BufferedReader

Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15694#pullrequestreview-1625154951

From jlu at openjdk.org  Wed Sep 13 18:46:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 13 Sep 2023 18:46:38 GMT
Subject: jmx-dev RFR: 8301991: Convert l10n properties resource bundles
 to UTF-8 native [v2]
In-Reply-To: <P4kk89ZhTNI88oojKYUPUAxLf1XgVj1Y4hL877t5uO8=.9b61c85a-d0e5-4980-ae7d-38f95a467083@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
 <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
 <P4kk89ZhTNI88oojKYUPUAxLf1XgVj1Y4hL877t5uO8=.9b61c85a-d0e5-4980-ae7d-38f95a467083@github.com>
Message-ID: <uMvl3FO1Vazr77Xov1P8ug2TNcA392WhIw_AK24e2B8=.6b6831ab-c30e-4804-9974-84ec0b9f97ae@github.com>

On Wed, 13 Sep 2023 18:12:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Looks good to me, although I did not look at each l10n file, but sampled some. Thanks for tackling this conversion.

Thanks for the review; (In addition to testing), I ran a script to verify only white space escape sequences exist in JDK .properties files. (Excluding escape sequences in test files that should remain as is for the purpose of the test)

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

PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-1718139807

From jlu at openjdk.org  Thu Sep 14 22:22:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 14 Sep 2023 22:22:50 GMT
Subject: jmx-dev Integrated: 8301991: Convert l10n properties resource
 bundles to UTF-8 native
In-Reply-To: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
Message-ID: <bMA2JRlOPK5QMgdE1cZJiNTZWJ5DH1Q0XLAY6c9YJ4w=.6476653b-6388-4f25-98ba-7ad80a6947cb@github.com>

On Tue, 12 Sep 2023 21:57:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
> 
> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
> 
> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
> 
> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
> 
> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).

This pull request has now been integrated.

Changeset: b55e418a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b55e418a077791b39992042411cde97f68dc39fe
Stats:     28964 lines in 488 files changed: 12 ins; 0 del; 28952 mod

8301991: Convert l10n properties resource bundles to UTF-8 native

Reviewed-by: naoto

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

PR: https://git.openjdk.org/jdk/pull/15694

From kevinw at openjdk.org  Fri Sep 15 08:48:53 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 15 Sep 2023 08:48:53 GMT
Subject: jmx-dev RFR: 8299560: Assertion failed: currentQueryIndex >= 0 &&
 currentQueryIndex < numberOfJavaProcessesAtInitialization
Message-ID: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>

This assert happens rarely, but is seen in testing a few times.

getCurrentQueryIndexForProcess comments that it can return -1, but it asserts that the value is >=0

If we let it return -1 for failure as its comment documents, the caller can handle the failure and not assert and end the JVM.  

Conversely, currentQueryIndexForProcess() clearly can return -1 on failure, so add the comment like we already have in getCurrentQueryIndexForProcess().

This assert is not reproducing on demand, but with this change I've done 50+ iterations of the test on windows-x64 and windows-x64-debug in mach5, and hundreds locally.

The test which has been seen to trigger the assert 
"test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java" 
...checks the range of the load value returned, and is happy enough if -1 is the answer.

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

Commit messages:
 - 8299560: Assertion failed: currentQueryIndex >= 0 && currentQueryIndex < numberOfJavaProcessesAtInitialization

Changes: https://git.openjdk.org/jdk/pull/15750/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15750&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299560
  Stats: 10 lines in 1 file changed: 2 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15750.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15750/head:pull/15750

PR: https://git.openjdk.org/jdk/pull/15750

From lmesnik at openjdk.org  Tue Sep 19 17:31:08 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 19 Sep 2023 17:31:08 GMT
Subject: jmx-dev RFR: 8316445: Mark
 com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java as vm.flagless
Message-ID: <FWLEo7JohBFfHjqO9KxvnF3A6jUwmnjBVb9GPC0wLWA=.6f80021d-23e9-463f-bf91-a9964f7c48dc@github.com>

Test
com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
check how beans work with VM flags and ignore external flags.
It doesn't make sense to run it with external options so just mark it as flagless.
Tested with running tier1 and test with/without additional options.

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

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/15823/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15823&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316445
  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15823.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15823/head:pull/15823

PR: https://git.openjdk.org/jdk/pull/15823

From lmesnik at openjdk.org  Wed Sep 20 22:11:12 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Sep 2023 22:11:12 GMT
Subject: jmx-dev RFR: 8316445: Mark
 com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java as vm.flagless
 [v2]
In-Reply-To: <FWLEo7JohBFfHjqO9KxvnF3A6jUwmnjBVb9GPC0wLWA=.6f80021d-23e9-463f-bf91-a9964f7c48dc@github.com>
References: <FWLEo7JohBFfHjqO9KxvnF3A6jUwmnjBVb9GPC0wLWA=.6f80021d-23e9-463f-bf91-a9964f7c48dc@github.com>
Message-ID: <NywYDfbS8Bz4vC7ZLOVOen_xk4pGqSgXmX8MJ8JLfyY=.9fc4db4f-332c-45b6-a92b-6804fc2c96f6@github.com>

> Test
> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
> check how beans work with VM flags and ignore external flags.
> It doesn't make sense to run it with external options so just mark it as flagless.
> Tested with running tier1 and test with/without additional options.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  Added support of Xmx option in makefiles testing.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15823/files
  - new: https://git.openjdk.org/jdk/pull/15823/files/48fa3c66..74369495

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15823&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15823&range=00-01

  Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15823.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15823/head:pull/15823

PR: https://git.openjdk.org/jdk/pull/15823

From cjplummer at openjdk.org  Wed Sep 20 22:11:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 20 Sep 2023 22:11:12 GMT
Subject: jmx-dev RFR: 8316445: Mark
 com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java as vm.flagless
 [v2]
In-Reply-To: <NywYDfbS8Bz4vC7ZLOVOen_xk4pGqSgXmX8MJ8JLfyY=.9fc4db4f-332c-45b6-a92b-6804fc2c96f6@github.com>
References: <FWLEo7JohBFfHjqO9KxvnF3A6jUwmnjBVb9GPC0wLWA=.6f80021d-23e9-463f-bf91-a9964f7c48dc@github.com>
 <NywYDfbS8Bz4vC7ZLOVOen_xk4pGqSgXmX8MJ8JLfyY=.9fc4db4f-332c-45b6-a92b-6804fc2c96f6@github.com>
Message-ID: <DWYpc1s5NUVLAIfP1T-W9mRI9jAKGd4oE8S8nWBgMjs=.7f52c183-4749-4f24-8616-0c984e770bc6@github.com>

On Wed, 20 Sep 2023 22:06:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Test
>> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
>> check how beans work with VM flags and ignore external flags.
>> It doesn't make sense to run it with external options so just mark it as flagless.
>> Tested with running tier1 and test with/without additional options.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added support of Xmx option in makefiles testing.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15823#pullrequestreview-1634277712

From lmesnik at openjdk.org  Wed Sep 20 22:11:40 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Sep 2023 22:11:40 GMT
Subject: jmx-dev RFR: 8299560: Assertion failed: currentQueryIndex >= 0
 && currentQueryIndex < numberOfJavaProcessesAtInitialization
In-Reply-To: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
References: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
Message-ID: <eD09JU7P9dwADuFYq3-z0_IZ0eYFPX0aQ_mV39CBWsg=.6369a72d-d134-42d1-8b15-f573bcbbb7ab@github.com>

On Thu, 14 Sep 2023 17:24:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This assert happens rarely, but is seen in testing a few times.
> 
> getCurrentQueryIndexForProcess comments that it can return -1, but it asserts that the value is >=0
> 
> If we let it return -1 for failure as its comment documents, the caller can handle the failure and not assert and end the JVM.  
> 
> Conversely, currentQueryIndexForProcess() clearly can return -1 on failure, so add the comment like we already have in getCurrentQueryIndexForProcess().
> 
> This assert is not reproducing on demand, but with this change I've done 50+ iterations of the test on windows-x64 and windows-x64-debug in mach5, and hundreds locally.
> 
> The test which has been seen to trigger the assert 
> "test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java" 
> ...checks the range of the load value returned, and is happy enough if -1 is the answer.

Changes requested by lmesnik (Reviewer).

src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 780:

> 778:     int currentQueryIndex = currentQueryIndexForProcess();
> 779: 
> 780:     assert(currentQueryIndex < numberOfJavaProcessesAtInitialization);

doesn't it make sense to change assert to currentQueryIndex >= -1, so any other negative numbers are still hit assertion?

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

PR Review: https://git.openjdk.org/jdk/pull/15750#pullrequestreview-1636577587
PR Review Comment: https://git.openjdk.org/jdk/pull/15750#discussion_r1332230115

From lmesnik at openjdk.org  Wed Sep 20 22:11:12 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 20 Sep 2023 22:11:12 GMT
Subject: jmx-dev RFR: 8316445: Mark
 com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java as vm.flagless
In-Reply-To: <FWLEo7JohBFfHjqO9KxvnF3A6jUwmnjBVb9GPC0wLWA=.6f80021d-23e9-463f-bf91-a9964f7c48dc@github.com>
References: <FWLEo7JohBFfHjqO9KxvnF3A6jUwmnjBVb9GPC0wLWA=.6f80021d-23e9-463f-bf91-a9964f7c48dc@github.com>
Message-ID: <gKApB4OKCWo6khyC1C2I_Vo6UGVfM4MNP6_9ObfuUH8=.f87c2b03-f507-4eb7-a602-bc8bfac2d367@github.com>

On Tue, 19 Sep 2023 17:24:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test
> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
> check how beans work with VM flags and ignore external flags.
> It doesn't make sense to run it with external options so just mark it as flagless.
> Tested with running tier1 and test with/without additional options.

The vm.flagless is fixed to be supported in JDK tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/15823#issuecomment-1728487948

From kevinw at openjdk.org  Tue Sep 26 09:02:15 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 26 Sep 2023 09:02:15 GMT
Subject: jmx-dev RFR: 8299560: Assertion failed: currentQueryIndex >= 0
 && currentQueryIndex < numberOfJavaProcessesAtInitialization
In-Reply-To: <eD09JU7P9dwADuFYq3-z0_IZ0eYFPX0aQ_mV39CBWsg=.6369a72d-d134-42d1-8b15-f573bcbbb7ab@github.com>
References: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
 <eD09JU7P9dwADuFYq3-z0_IZ0eYFPX0aQ_mV39CBWsg=.6369a72d-d134-42d1-8b15-f573bcbbb7ab@github.com>
Message-ID: <1YduXrvnJounlOzWR66Z30aMfsg2jB4F1JikuNfvpx4=.5325045e-8287-4f73-9d71-adf5014c94c0@github.com>

On Wed, 20 Sep 2023 22:08:27 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> This assert happens rarely, but is seen in testing a few times.
>> 
>> getCurrentQueryIndexForProcess comments that it can return -1, but it asserts that the value is >=0
>> 
>> If we let it return -1 for failure as its comment documents, the caller can handle the failure and not assert and end the JVM.  
>> 
>> Conversely, currentQueryIndexForProcess() clearly can return -1 on failure, so add the comment like we already have in getCurrentQueryIndexForProcess().
>> 
>> This assert is not reproducing on demand, but with this change I've done 50+ iterations of the test on windows-x64 and windows-x64-debug in mach5, and hundreds locally.
>> 
>> The test which has been seen to trigger the assert 
>> "test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java" 
>> ...checks the range of the load value returned, and is happy enough if -1 is the answer.
>
> src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 780:
> 
>> 778:     int currentQueryIndex = currentQueryIndexForProcess();
>> 779: 
>> 780:     assert(currentQueryIndex < numberOfJavaProcessesAtInitialization);
> 
> doesn't it make sense to change assert to currentQueryIndex >= -1, so any other negative numbers are still hit assertion?

Thanks Leonid, I didn't see much value in that - we can see in the same file the return value of currentQueryIndexForProcess() is going to be -1 or an index from the for loop iteration from 0 to INT_MAX.
We can do that if you really feel it has a benefit?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15750#discussion_r1336871050

From lmesnik at openjdk.org  Tue Sep 26 16:53:13 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 26 Sep 2023 16:53:13 GMT
Subject: jmx-dev RFR: 8299560: Assertion failed: currentQueryIndex >= 0
 && currentQueryIndex < numberOfJavaProcessesAtInitialization
In-Reply-To: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
References: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
Message-ID: <ZaCqnNANwVjRAGudreJnIn4qmvQIbWnbpBNumznumLY=.ccc7787b-1a89-4a7c-aed3-fbf4998443a9@github.com>

On Thu, 14 Sep 2023 17:24:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This assert happens rarely, but is seen in testing a few times.
> 
> getCurrentQueryIndexForProcess comments that it can return -1, but it asserts that the value is >=0
> 
> If we let it return -1 for failure as its comment documents, the caller can handle the failure and not assert and end the JVM.  
> 
> Conversely, currentQueryIndexForProcess() clearly can return -1 on failure, so add the comment like we already have in getCurrentQueryIndexForProcess().
> 
> This assert is not reproducing on demand, but with this change I've done 50+ iterations of the test on windows-x64 and windows-x64-debug in mach5, and hundreds locally.
> 
> The test which has been seen to trigger the assert 
> "test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java" 
> ...checks the range of the load value returned, and is happy enough if -1 is the answer.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15750#pullrequestreview-1644766850

From lmesnik at openjdk.org  Tue Sep 26 16:53:15 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 26 Sep 2023 16:53:15 GMT
Subject: jmx-dev RFR: 8299560: Assertion failed: currentQueryIndex >= 0
 && currentQueryIndex < numberOfJavaProcessesAtInitialization
In-Reply-To: <1YduXrvnJounlOzWR66Z30aMfsg2jB4F1JikuNfvpx4=.5325045e-8287-4f73-9d71-adf5014c94c0@github.com>
References: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
 <eD09JU7P9dwADuFYq3-z0_IZ0eYFPX0aQ_mV39CBWsg=.6369a72d-d134-42d1-8b15-f573bcbbb7ab@github.com>
 <1YduXrvnJounlOzWR66Z30aMfsg2jB4F1JikuNfvpx4=.5325045e-8287-4f73-9d71-adf5014c94c0@github.com>
Message-ID: <YNoJZoBKWvuJbq7OY4wQQqKRUti6CVfrznRsJLtcd3U=.cc7cb42b-71ba-4fe1-982f-807179d99ce6@github.com>

On Tue, 26 Sep 2023 08:59:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 780:
>> 
>>> 778:     int currentQueryIndex = currentQueryIndexForProcess();
>>> 779: 
>>> 780:     assert(currentQueryIndex < numberOfJavaProcessesAtInitialization);
>> 
>> doesn't it make sense to change assert to currentQueryIndex >= -1, so any other negative numbers are still hit assertion?
>
> Thanks Leonid, I didn't see much value in that - we can see in the same file the return value of currentQueryIndexForProcess() is going to be -1 or an index from the for loop iteration from 0 to INT_MAX.
> We can do that if you really feel it has a benefit?

Fine then. Thank you for the explanation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15750#discussion_r1337521726

From cjplummer at openjdk.org  Tue Sep 26 19:31:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 26 Sep 2023 19:31:12 GMT
Subject: jmx-dev RFR: 8299560: Assertion failed: currentQueryIndex >= 0
 && currentQueryIndex < numberOfJavaProcessesAtInitialization
In-Reply-To: <YNoJZoBKWvuJbq7OY4wQQqKRUti6CVfrznRsJLtcd3U=.cc7cb42b-71ba-4fe1-982f-807179d99ce6@github.com>
References: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
 <eD09JU7P9dwADuFYq3-z0_IZ0eYFPX0aQ_mV39CBWsg=.6369a72d-d134-42d1-8b15-f573bcbbb7ab@github.com>
 <1YduXrvnJounlOzWR66Z30aMfsg2jB4F1JikuNfvpx4=.5325045e-8287-4f73-9d71-adf5014c94c0@github.com>
 <YNoJZoBKWvuJbq7OY4wQQqKRUti6CVfrznRsJLtcd3U=.cc7cb42b-71ba-4fe1-982f-807179d99ce6@github.com>
Message-ID: <qa-5rEp4qUqvug4ctX4qI3UKb2f-AWTuPWk5xzFWU4E=.c66f8bd2-4813-411e-9a43-6bed1d6d9079@github.com>

On Tue, 26 Sep 2023 16:50:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Thanks Leonid, I didn't see much value in that - we can see in the same file the return value of currentQueryIndexForProcess() is going to be -1 or an index from the for loop iteration from 0 to INT_MAX.
>> We can do that if you really feel it has a benefit?
>
> Fine then. Thank you for the explanation.

What was the cause of all the 0's in the output, and how did you get rid of them so you could see the assert message?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15750#discussion_r1337685340

From kevinw at openjdk.org  Wed Sep 27 10:39:13 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 27 Sep 2023 10:39:13 GMT
Subject: jmx-dev RFR: 8299560: Assertion failed: currentQueryIndex >= 0
 && currentQueryIndex < numberOfJavaProcessesAtInitialization
In-Reply-To: <qa-5rEp4qUqvug4ctX4qI3UKb2f-AWTuPWk5xzFWU4E=.c66f8bd2-4813-411e-9a43-6bed1d6d9079@github.com>
References: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
 <eD09JU7P9dwADuFYq3-z0_IZ0eYFPX0aQ_mV39CBWsg=.6369a72d-d134-42d1-8b15-f573bcbbb7ab@github.com>
 <1YduXrvnJounlOzWR66Z30aMfsg2jB4F1JikuNfvpx4=.5325045e-8287-4f73-9d71-adf5014c94c0@github.com>
 <YNoJZoBKWvuJbq7OY4wQQqKRUti6CVfrznRsJLtcd3U=.cc7cb42b-71ba-4fe1-982f-807179d99ce6@github.com>
 <qa-5rEp4qUqvug4ctX4qI3UKb2f-AWTuPWk5xzFWU4E=.c66f8bd2-4813-411e-9a43-6bed1d6d9079@github.com>
Message-ID: <7X_6BshZwPdh-WJoMxRHMA1WxS8pb4GFMyQ4lsLEi7U=.84aacfc8-638d-499e-be68-15e6340a83d8@github.com>

On Tue, 26 Sep 2023 19:28:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Fine then. Thank you for the explanation.
>
> What was the cause of all the 0's in the output, and how did you get rid of them so you could see the assert message?

Thanks Leonid!

On the \u0000 content, I don't see that mess in the console (cygwin) if I make these asserts trigger in a local windows build and test.
But I do see the \u0000... in the .jtr file created by jtreg.  So a character encoding disagreement when the output is captured and saved..?  The jtreg faq mentions this, https://openjdk.org/jtreg/faq.html but I haven't worked on it further.

In logs/bug reports that have them, I just search and replace to remove them...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15750#discussion_r1338409202

From cjplummer at openjdk.org  Wed Sep 27 15:48:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 27 Sep 2023 15:48:13 GMT
Subject: jmx-dev RFR: 8299560: Assertion failed: currentQueryIndex >= 0
 && currentQueryIndex < numberOfJavaProcessesAtInitialization
In-Reply-To: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
References: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
Message-ID: <gJSFLjHjqUJ2SNIilQfEp1qpGDPtpFjC5OoJAFBvYH4=.008de2c2-f9da-425d-b1d7-009b12551121@github.com>

On Thu, 14 Sep 2023 17:24:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This assert happens rarely, but is seen in testing a few times.
> 
> getCurrentQueryIndexForProcess comments that it can return -1, but it asserts that the value is >=0
> 
> If we let it return -1 for failure as its comment documents, the caller can handle the failure and not assert and end the JVM.  
> 
> Conversely, currentQueryIndexForProcess() clearly can return -1 on failure, so add the comment like we already have in getCurrentQueryIndexForProcess().
> 
> This assert is not reproducing on demand, but with this change I've done 50+ iterations of the test on windows-x64 and windows-x64-debug in mach5, and hundreds locally.
> 
> The test which has been seen to trigger the assert 
> "test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java" 
> ...checks the range of the load value returned, and is happy enough if -1 is the answer.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15750#pullrequestreview-1647041495

From kevinw at openjdk.org  Wed Sep 27 15:57:25 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 27 Sep 2023 15:57:25 GMT
Subject: jmx-dev RFR: 8299560: Assertion failed: currentQueryIndex >= 0
 && currentQueryIndex < numberOfJavaProcessesAtInitialization
In-Reply-To: <7X_6BshZwPdh-WJoMxRHMA1WxS8pb4GFMyQ4lsLEi7U=.84aacfc8-638d-499e-be68-15e6340a83d8@github.com>
References: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
 <eD09JU7P9dwADuFYq3-z0_IZ0eYFPX0aQ_mV39CBWsg=.6369a72d-d134-42d1-8b15-f573bcbbb7ab@github.com>
 <1YduXrvnJounlOzWR66Z30aMfsg2jB4F1JikuNfvpx4=.5325045e-8287-4f73-9d71-adf5014c94c0@github.com>
 <YNoJZoBKWvuJbq7OY4wQQqKRUti6CVfrznRsJLtcd3U=.cc7cb42b-71ba-4fe1-982f-807179d99ce6@github.com>
 <qa-5rEp4qUqvug4ctX4qI3UKb2f-AWTuPWk5xzFWU4E=.c66f8bd2-4813-411e-9a43-6bed1d6d9079@github.com>
 <7X_6BshZwPdh-WJoMxRHMA1WxS8pb4GFMyQ4lsLEi7U=.84aacfc8-638d-499e-be68-15e6340a83d8@github.com>
Message-ID: <uOvtVsKv96QDy3dKnbAsFqBkDo7cuKZiwj7P-uqWzVs=.bc9da3a1-8ff3-46df-8df4-aae27c000070@github.com>

On Wed, 27 Sep 2023 10:36:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> What was the cause of all the 0's in the output, and how did you get rid of them so you could see the assert message?
>
> Thanks Leonid!
> 
> On the \u0000 content, I don't see that mess in the console (cygwin) if I make these asserts trigger in a local windows build and test.
> But I do see the \u0000... in the .jtr file created by jtreg.  So a character encoding disagreement when the output is captured and saved..?  The jtreg faq mentions this, https://openjdk.org/jtreg/faq.html but I haven't worked on it further.
> 
> In logs/bug reports that have them, I just search and replace to remove them...

Thanks Chris!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15750#discussion_r1338830889

From kevinw at openjdk.org  Wed Sep 27 15:57:27 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 27 Sep 2023 15:57:27 GMT
Subject: jmx-dev Integrated: 8299560: Assertion failed: currentQueryIndex >=
 0 && currentQueryIndex < numberOfJavaProcessesAtInitialization
In-Reply-To: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
References: <jN23UhCyjYwHtB-jZyEMnmtVgcmjNr0eGS8UvvGkeT4=.d7d57b69-6220-4325-95fc-cfca96af1bbc@github.com>
Message-ID: <iRfwnM5AXiubtH7iwcPrgC72psGxpzroGo55b8ho0Ik=.53f7e569-6901-43e8-bc9d-62bfb8916f14@github.com>

On Thu, 14 Sep 2023 17:24:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This assert happens rarely, but is seen in testing a few times.
> 
> getCurrentQueryIndexForProcess comments that it can return -1, but it asserts that the value is >=0
> 
> If we let it return -1 for failure as its comment documents, the caller can handle the failure and not assert and end the JVM.  
> 
> Conversely, currentQueryIndexForProcess() clearly can return -1 on failure, so add the comment like we already have in getCurrentQueryIndexForProcess().
> 
> This assert is not reproducing on demand, but with this change I've done 50+ iterations of the test on windows-x64 and windows-x64-debug in mach5, and hundreds locally.
> 
> The test which has been seen to trigger the assert 
> "test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java" 
> ...checks the range of the load value returned, and is happy enough if -1 is the answer.

This pull request has now been integrated.

Changeset: 5350fd61
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5350fd617390aaaedf8dd8821418c796cb1c38b3
Stats:     10 lines in 1 file changed: 2 ins; 2 del; 6 mod

8299560: Assertion failed: currentQueryIndex >= 0 && currentQueryIndex < numberOfJavaProcessesAtInitialization

Reviewed-by: lmesnik, cjplummer

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

PR: https://git.openjdk.org/jdk/pull/15750

From sspitsyn at openjdk.org  Thu Sep 28 16:59:28 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 28 Sep 2023 16:59:28 GMT
Subject: jmx-dev RFR: 8316445: Mark
 com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java as vm.flagless
 [v2]
In-Reply-To: <NywYDfbS8Bz4vC7ZLOVOen_xk4pGqSgXmX8MJ8JLfyY=.9fc4db4f-332c-45b6-a92b-6804fc2c96f6@github.com>
References: <FWLEo7JohBFfHjqO9KxvnF3A6jUwmnjBVb9GPC0wLWA=.6f80021d-23e9-463f-bf91-a9964f7c48dc@github.com>
 <NywYDfbS8Bz4vC7ZLOVOen_xk4pGqSgXmX8MJ8JLfyY=.9fc4db4f-332c-45b6-a92b-6804fc2c96f6@github.com>
Message-ID: <idlii8g-YUZd3fMDSOsqdJ6Msnjkgb35QePrK4mQgp0=.1bab079e-ec26-4d29-b2f6-b6b2a0729d4b@github.com>

On Wed, 20 Sep 2023 22:11:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Test
>> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
>> check how beans work with VM flags and ignore external flags.
>> It doesn't make sense to run it with external options so just mark it as flagless.
>> Tested with running tier1 and test with/without additional options.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added support of Xmx option in makefiles testing.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15823#pullrequestreview-1649334238

From lmesnik at openjdk.org  Thu Sep 28 17:18:35 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 28 Sep 2023 17:18:35 GMT
Subject: jmx-dev Integrated: 8316445: Mark
 com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java as vm.flagless
In-Reply-To: <FWLEo7JohBFfHjqO9KxvnF3A6jUwmnjBVb9GPC0wLWA=.6f80021d-23e9-463f-bf91-a9964f7c48dc@github.com>
References: <FWLEo7JohBFfHjqO9KxvnF3A6jUwmnjBVb9GPC0wLWA=.6f80021d-23e9-463f-bf91-a9964f7c48dc@github.com>
Message-ID: <t_Tj8MSO1lnocqTPXOsT7UIxC95NkMJKRkiYhPx6ipU=.e1a254e3-65d1-4671-8132-42bfb7f694bf@github.com>

On Tue, 19 Sep 2023 17:24:15 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test
> com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java
> check how beans work with VM flags and ignore external flags.
> It doesn't make sense to run it with external options so just mark it as flagless.
> Tested with running tier1 and test with/without additional options.

This pull request has now been integrated.

Changeset: ca5eee2f
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca5eee2fe37959f54c5efe557f271dea0a0baef4
Stats:     12 lines in 3 files changed: 6 ins; 0 del; 6 mod

8316445: Mark com/sun/management/HotSpotDiagnosticMXBean/CheckOrigin.java as vm.flagless

Reviewed-by: cjplummer, sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/15823