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:
>
> ![image](https://github.com/openjdk/jdk/assets/24123821/13f0eae2-71
On Mon, 11 Mar 2024 15:15:39 GMT, Naoto Sato wrote:
> LGTM
@naotoj Thanks for the review.
-
PR Comment: https://git.openjdk.org/jdk/pull/18155#issuecomment-2043989340
On Sat, 9 Mar 2024 13:18:14 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
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:
>
> ![image](https://github.com/openjdk/jdk/assets/24123821/13f0eae2-71
Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all the
files in build/linux-x86_64-server-release/images/jdk/bin are executable:
![image](https://github.com/openjdk/jdk/assets/24123821/13f0eae2-7125-4d09-8793-8a5a10b785c2)
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:
27 matches
Mail list logo