On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote:
>> Hi all,
>> This PR several extra empty spaces and extra empty lines in several
>> Makefiles. It's trivial fix, no risk.
>>
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
This pull request has now been integrated.
Changeset: d130d2f4
Author:SendaoYan
Co
On Fri, 7 Jun 2024 12:53:46 GMT, Chen Liang wrote:
>> No, it's an extra newline. A file should end with a newline but one is
>> enough.
>
> As confusing as they are, unfortunately GitHub UI does not render extra
> trailing newlines. This is the only one I could find with grepWin.
I find the
On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote:
>> Hi all,
>> This PR several extra empty spaces and extra empty lines in several
>> Makefiles. It's trivial fix, no risk.
>>
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one
On Thu, 6 Jun 2024 17:49:08 GMT, Chen Liang wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> delete extra empty trailing blank line in
>> test/jdk/java/rmi/reliability/benchmark/bench/
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
delete extra empty trailing blank li
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
Thanks for the review.
Thanks all for the review.
-
PR Comment: https://git.
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
> /label build
Thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/
Hi all,
This PR several extra empty spaces and extra empty lines in several
Makefiles. It's trivial fix, no risk.
Thanks.
-
Commit messages:
- 8333477: Delete extra empty spaces in Makefiles
Changes: https://git.openjdk.org/jdk/pull/19537/files
Webrev:
On Sun, 26 May 2024 07:24:16 GMT, SendaoYan wrote:
>> Hi all,
>> When there is no `/usr/bin/expect` in system, `throw new SkippedException`
>> will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause
>> this testcase run failed. So I mak
On Sun, 26 May 2024 02:58:02 GMT, SendaoYan wrote:
> Hi all,
> When there is no `/usr/bin/expect` in system, `throw new SkippedException`
> will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause
> this testcase run failed. So I make change fro
On Sun, 26 May 2024 07:40:38 GMT, Daniel Jeliński wrote:
> LGTM. I assume you verified it does the right thing.
Thanks for the review and approved. The change has been verified.
-
PR Comment: https://git.openjdk.org/jdk/pull/19403#issuecomment-2132120584
On Sun, 26 May 2024 06:16:44 GMT, Alan Bateman wrote:
>> test/jdk/java/io/IO/IO.java line 64:
>>
>>> 62: expect = Paths.get("/usr/bin/expect"); // os-specific path
>>> 63: if (!Files.exists(expect) || !Files.isExecutable(expect)) {
>>> 64:
issue. When use `System.exit`, I think we
> should use `othervm` mode in jtreg.
> Only change the testcase, the risk is low.
>
> Thanks.
SendaoYan has updated the pull request incrementally with two additional
commits since the last revision:
- delete "static final int JCK_
Hi all,
When there is no `/usr/bin/expect` in system, `throw new SkippedException`
will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause
this testcase run failed. So I make change from `throw new SkippedException` to
`System.exit` to avoid this issue. When use
On Wed, 15 May 2024 03:28:29 GMT, SendaoYan wrote:
> Hi all,
> The `tools/jlink/JLinkReproducibleTest.java` intermittent fails on linux
> aarch64. Should we mark this testcase as `@key intermittent`. No risk.
>
> Thanks.
> -sendao
This pull request has been closed withou
On Wed, 15 May 2024 03:41:02 GMT, Jaikiran Pai wrote:
> Hello @sendaoYan, the linked issue
> https://bugs.openjdk.org/browse/JDK-8327181 which talks about a JVM crash
> looks very generic and not specific to this test. Before updating this test,
> I think that issue needs to
Hi all,
The `tools/jlink/JLinkReproducibleTest.java` intermittent fails on linux
aarch64. Should we mark this testcase as `@key intermittent`. No risk.
Thanks.
-sendao
-
Commit messages:
- 8332260: mark tools/jlink/JLinkReproducibleTest.java as intermittent failure
- 8332260:
On Tue, 23 Jan 2024 13:04:43 GMT, SendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> SendaoYan has updated the pull request incrementally with one additional
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
>  uses Locale.US explicitly for printing the time zone, so
>> replace Locale.ROOT to Locale.US in this testcase for fix the test failure.
>>
>> This testcase fixed has been verified.
>>
>> O
On Thu, 7 Mar 2024 16:47:01 GMT, SendaoYan wrote:
> Date.toString() uses Locale.US explicitly for printing the time zone, so
> replace Locale.ROOT to Locale.US in this testcase for fix the test failure.
>
> This testcase fixed has been verified.
>
> Only change the tes
> Date.toString() uses Locale.US explicitly for printing the time zone, so
> replace Locale.ROOT to Locale.US in this testcase for fix the test failure.
>
> This testcase fixed has been verified.
>
> Only change the testcase, risk is low.
SendaoYan has updated the pull req
On Fri, 8 Mar 2024 17:29:09 GMT, Naoto Sato wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update the Locale.US code comment
>>
>> Signed-off-by: sendaoYa
On Thu, 7 Mar 2024 21:07:12 GMT, Naoto Sato wrote:
> Thanks for the fix. Although setting `Locale.US` to acquire the formatter is
> correct, the reasoning is not. The real reason is that `Date.toString()` uses
> `Locale.US` explicitly for printing the time zone
>
>
On Fri, 8 Mar 2024 02:41:06 GMT, SendaoYan wrote:
>> Date.toString() uses Locale.US explicitly for printing the time zone, so
>> replace Locale.ROOT to Locale.US in this testcase for fix the test failure.
>>
>> This testcase fixed has been verified.
>>
>> O
> The DATE_FORMAT_PATTERN is set to "EEE MMM dd HH:mm:ss zzz ", is the time
> format of US. So, creates a formatter should using Locale.US, rather than
> Locale.ROOT, which means empty.
SendaoYan has updated the pull request incrementally with one additional commit
sinc
The DATE_FORMAT_PATTERN is set to "EEE MMM dd HH:mm:ss zzz ", is the time
format of US. So, creates a formatter should using Locale.US, rather than
Locale.ROOT, which means empty.
-
Commit messages:
- 8327486: java/util/Properties/PropertiesStoreTest.java fails "Text 'xxx'
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
> , all the
files in build/linux-x86_64-server-release/images/jdk/bin are executable:
After JDK-8325342, all the *.debuginfo files
On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan wrote:
> 8323640: [TESTBUG]testMemoryFailCount in
> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
> OOM killed
This pull request has now been integrated.
Changeset: 791b427f
Author:sendaoYan
Committer
On Tue, 23 Jan 2024 13:04:43 GMT, sendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional
> 8323640: [TESTBUG]testMemoryFailCount in
> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
> OOM killed
sendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
8323640: [TESTBUG]testMemoryFailCoun
> 8323640: [TESTBUG]testMemoryFailCount in
> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
> OOM killed
sendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
8323640: [TESTBUG]testMemoryFailCoun
On Mon, 22 Jan 2024 15:03:18 GMT, Severin Gehwolf wrote:
> `1k` increments for a total of `512k` times seems overkill. Are you sure
> that's needed to make the test pass? How about `1MB` increments for a total
> of `512` times?
When the docker serivice work normally on the test machine, this
On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan wrote:
> 8323640: [TESTBUG]testMemoryFailCount in
> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
> OOM killed
The test case before this PR has a maximum heap of 64MB and applies for 8M of
memory
8323640: [TESTBUG]testMemoryFailCount in
jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
OOM killed
-
Commit messages:
- 8323640: [TESTBUG]testMemoryFailCount in
jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
OOM
On Fri, 12 Jan 2024 03:31:37 GMT, sendaoYan wrote:
> 8323640: [TESTBUG]testMemoryFailCount in
> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
> OOM killed
This pull request has been closed without being integrated.
-
PR: https://git.op
> 8323640: [TESTBUG]testMemoryFailCount in
> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
> OOM killed
sendaoYan has refreshed the contents of this pull request, and previous commits
have been removed. The incremental views will show differences
On Fri, 12 Jan 2024 03:31:37 GMT, sendaoYan wrote:
> Reviewed-by: Yi Yang
The test case before this PR has a maximum heap of 64MB and applies for 8M of
memory each time in the for loop. When applying for memory for the sixth time,
it was killed by the docker container because of
Reviewed-by: Yi Yang
-
Commit messages:
- 8323640: [TESTBUG]testMemoryFailCount in
jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
OOM killed
Changes: https://git.openjdk.org/jdk/pull/17386/files
Webrev:
42 matches
Mail list logo
