On Wed, 11 Jun 2025 07:15:43 GMT, SendaoYan wrote:
> Hi all,
>
> I think use `@requires (os.family == "windows")` is more elegant than thow
> jtreg.SkippedException in test java/io/File/MaxPath.java.
>
> On linux before this PR, run this test jtreg report
On Wed, 11 Jun 2025 22:37:53 GMT, Brent Christian wrote:
>> Hi all,
>>
>> I think use `@requires (os.family == "windows")` is more elegant than thow
>> jtreg.SkippedException in test java/io/File/MaxPath.java.
>>
>> On linux before this PR, run this test jtreg report:
>>
>>
>> TEST: java/io/
Hi all,
I think use `@requires (os.family == "windows")` is more elegrant than thow
jtreg.SkippedException in test java/io/File/MaxPath.java.
On linux before this PR, run this test jtreg report:
TEST: java/io/File/MaxPath.java
TEST RESULT: Passed. Skipped: jtreg.SkippedException: This test is
On Sun, 8 Jun 2025 09:07:11 GMT, He-Pin(kerr) wrote:
> Rename auxilliary to auxiliary
Marked as reviewed by syan (Committer).
What does `chore` mean
I create a JBS issue for this PR
https://bugs.openjdk.org/browse/JDK-8359067, you should change the PR title to
"8359067: Fix typo in DelaySch
On Mon, 2 Jun 2025 21:48:04 GMT, Naoto Sato wrote:
> Fixing a regression caused by the fix to JDK-8356985. Although the fix in
> `CharsetTest` was a clean-up and not the gist of the original issue, the
> change seem to have caused not finding `SkippedException` at runtime in
> certain cases. C
On Sat, 31 May 2025 17:27:30 GMT, Ian Graves wrote:
>> Removing incorrect assumptions and assertions from a breaking test related
>> to https://bugs.openjdk.org/browse/JDK-8358218
>
> Ian Graves has updated the pull request with a new target base due to a merge
> or a rebase. The pull request n
On Mon, 26 May 2025 15:48:10 GMT, Steffen Nießing wrote:
>> `Proxy#getInvocationHandler(Object)` throws a `NullPointerException` if the
>> specified argument is `null`. This PR adds the missing `throws` declaration
>> for the NPE.
>
> Steffen Nießing has updated the pull request incrementally w
On Thu, 22 May 2025 14:19:09 GMT, Viktor Klang wrote:
> Barring other effects, it is likely that this test just needs to have some
> longer timeouts to ensure that a stall isn't likely to fail the test case.
> The shouldn't have any impact on test execution duration, as the test looks
> at tas
On Thu, 22 May 2025 08:31:06 GMT, serhiysachkov wrote:
>> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as
>> manual
>
> serhiysachkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8357462: copyright update
LGTM
On Wed, 21 May 2025 13:44:09 GMT, serhiysachkov wrote:
> Amend open/test/jdk//java/foreign/TestMatrix.java test scenario to run as
> manual
Changes requested by syan (Committer).
test/jdk/java/foreign/TestMatrix.java line 38:
> 36: * @build NativeTestHelper CallGeneratorHelper TestUpcallHigh
On Tue, 20 May 2025 15:25:52 GMT, Michael McMahon wrote:
> Hi,
>
> This is a simple test update which increases a timeout from 300s to 400 to
> account for slow mac os test machines.
> A repeat 50 test of :jdk_lang passes. I will run this a few more times before
> pushing, if the change is acc
On Tue, 13 May 2025 21:28:00 GMT, Jiangli Zhou wrote:
> Please review this PR for skipping
> jdk/test/lib/process/TestNativeProcessBuilder on static-jdk. Duplicating the
> context from https://bugs.openjdk.org/browse/JDK-8356904 description:
>
> jdk/test/lib/process/TestNativeProcessBuilder.ja
On Fri, 9 May 2025 15:39:35 GMT, Andrew Haley wrote:
>> This intrinsic is generally faster than the current implementation for
>> Panama segment operations for all writes larger than about 8 bytes in size,
>> increasing to more than 2* the performance on larger memory blocks on
>> Graviton 2,
On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
>
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a
> released jdk not supportting sleef (for any reason, e.g. low gcc version,
> intrinsic not supported, rvv not supported,
On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang wrote:
>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>>
>> For calling little color management system
>> https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>>
>>
On Mon, 28 Apr 2025 14:36:33 GMT, Chen Liang wrote:
>> Perf numbers for simple main:
>> Linking of `Class::forName0` down from ~152 to ~83
>>
>> For calling little color management system
>> https://bugs.openjdk.org/browse/JDK-8313344:
>> JNI: ~45
>> baseline panama: ~164
>> patch: ~103
>>
>>
On Wed, 16 Apr 2025 23:41:40 GMT, Jiangli Zhou wrote:
> Please review this simple test change that skips the test case loading using
> JDK `libzip.so` on static JDK in
> test/jdk/jdk/internal/loader/NativeLibraries/Main.java. AFAICT, the test case
> using `NativeLibrariesTest.LIB_NAME` (`libna
On Wed, 16 Apr 2025 08:58:34 GMT, Xiaohong Gong wrote:
> ### Summary:
> [JDK-8318650](http://java-service.client.nvidia.com/?q=8318650) added the
> hotspot intrinsifying of subword gather load APIs for X86 platforms [1]. This
> patch aims at implementing the equivalent functionality for AArch64
On Fri, 18 Apr 2025 21:26:23 GMT, Joe Wang wrote:
>> Fix a NPE on calling DocumentBuilderFactory::getAttribute, refer to the bug
>> report.
>>
>> Also in this patch: consolidates get and set properties to use the same Util
>> methods to reduce potential errors when code changes.
>>
>> Test:
>
error -O0 -c java.c -fsanitize=address
> java.c: In function ‘a’:
> java.c:6:1: error: control reaches end of non-void function
> [-Werror=return-type]
> 6 | }
> | ^
> cc1: all warnings being treated as errors
SendaoYan has updated the pull request incrementally with one
On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie wrote:
> While I normally advocate using DISABLE_WARNING in makefiles instead of
> pragmas, in this particular case I wonder if not a pragma in the `LEAVE`
> macro would be better?
PR has been changed to use `#pragma GCC diagnostic ignored "
On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie wrote:
>> Hi all,
>> File src/java.base/share/native/libjli/java.c compile error: control reaches
>> end of non-void function [-Werror=return-type] with gcc options
>> -fsanitize=address -O0. The function int JavaMain(void* _args) in this fil
On Sun, 30 Mar 2025 15:07:36 GMT, SendaoYan wrote:
> Hi all,
> File src/java.base/share/native/libjli/java.c compile error: control reaches
> end of non-void function [-Werror=return-type] with gcc options
> -fsanitize=address -O0. The function int JavaMain(void* _args) in this
error -O0 -c java.c -fsanitize=address
> java.c: In function ‘a’:
> java.c:6:1: error: control reaches end of non-void function
> [-Werror=return-type]
> 6 | }
> | ^
> cc1: all warnings being treated as errors
SendaoYan has updated the pull request incrementally with one
On Mon, 31 Mar 2025 12:57:38 GMT, Magnus Ihse Bursie wrote:
> in this particular case I wonder if not a pragma in the LEAVE macro would be
> better?
I will try it later.
-
PR Comment: https://git.openjdk.org/jdk/pull/24318#issuecomment-2766150226
Hi all,
File src/java.base/share/native/libjli/java.c compile error: control reaches
end of non-void function [-Werror=return-type] with gcc options
-fsanitize=address -O0. The function int JavaMain(void* _args) in this file
will execute return ret in LEAVE() macro, but gcc with -O0 is not smart
On Sat, 29 Mar 2025 01:32:19 GMT, Vladimir Ivanov wrote:
>> Hi all,
>>
>> The return type of function `const __m256i &perm` is `__m256i`, so `const
>> __m256i &perm` should be replaced as 'const __m256i perm'.
>>
>> The function implementation in gcc/clang compiler header:
>>
>> 1. gcc: lib/g
On Thu, 6 Mar 2025 03:35:20 GMT, SendaoYan wrote:
> Hi all,
>
> The return type of function `const __m256i &perm` is `__m256i`, so `const
> __m256i &perm` should be replaced as 'const __m256i perm'.
>
> The function implementation in gcc/clang compiler he
On Thu, 6 Mar 2025 03:35:20 GMT, SendaoYan wrote:
> Hi all,
>
> The return type of function `const __m256i &perm` is `__m256i`, so `const
> __m256i &perm` should be replaced as 'const __m256i perm'.
>
> The function implementation in gcc/clang compiler he
On Tue, 4 Feb 2025 12:35:50 GMT, SendaoYan wrote:
> Hi all,
>
> Several JMH tests fails "cannot access class
> jdk.internal.vm.ContinuationScope (in module java.base) because module
> java.base does not export jdk.internal.vm to unnamed module". This PR add VM
On Wed, 5 Mar 2025 16:15:55 GMT, Alan Bateman wrote:
>> Should we remove these JMH tests, or just fix the test bug and make tests
>> run normally
>
>> Should we remove these JMH tests, or just fix the test bug and make tests
>> run normally
>
> I think that would be best as they are left over
Hi all,
The return type of function `const __m256i &perm` is `__m256i`, so `const
__m256i &perm` should be replaced as 'const __m256i perm'.
The function implementation in gcc/clang compiler header:
1. gcc: lib/gcc/x86_64-pc-linux-gnu/14.2.0/include/avxintrin.h
extern __inline __m256i __attri
On Thu, 6 Mar 2025 03:35:20 GMT, SendaoYan wrote:
> Hi all,
>
> The return type of function `const __m256i &perm` is `__m256i`, so `const
> __m256i &perm` should be replaced as 'const __m256i perm'.
>
> The function implementation in gcc/clang compiler he
On Wed, 5 Mar 2025 16:15:55 GMT, Alan Bateman wrote:
> > Should we remove these JMH tests, or just fix the test bug and make tests
> > run normally
>
> I think that would be best as they are left over from early development.
The related test files has been removed in this PR.
-
P
=ALL-UNNAMED` to fix the JMH
> test bug.
>
> Change has been verified locally, test-fix only, no risk.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
Remove test/micro/org/openjdk/bench/loom/obsolete/FreezeAndThaw.java
test/
On Tue, 4 Feb 2025 12:35:50 GMT, SendaoYan wrote:
> Hi all,
>
> Several JMH tests fails "cannot access class
> jdk.internal.vm.ContinuationScope (in module java.base) because module
> java.base does not export jdk.internal.vm to unnamed module". This PR add VM
Hi all,
The newly added JMH test
jdk.incubator.vector.VectorCommutativeOperSharingBenchmark run fails
"java.lang.NoClassDefFoundError: jdk/incubator/vector/Vector".
The `@Fork(jvmArgsPrepend = ..)` in microbenchmarks should replaced as
`@Fork(jvmArgs = ..)` after
[JDK-8343345](https://bugs.op
On Thu, 20 Feb 2025 17:32:06 GMT, Joe Wang wrote:
>> Hi all,
>>
>> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes
>> unexpectedly when missing the depentdent file
>> test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a
>> NULL check after call
On Fri, 14 Feb 2025 07:44:26 GMT, SendaoYan wrote:
> Hi all,
>
> Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes
> unexpectedly when missing the depentdent file
> test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a
> NUL
On Thu, 20 Feb 2025 17:32:06 GMT, Joe Wang wrote:
> Yes, that would do.
Thanks, PR has been updated.
-
PR Comment: https://git.openjdk.org/jdk/pull/23627#issuecomment-2673138446
xsd")`.
>
> This PR do not change the original test logic but make test more robustness.
> Change has been verified locally, test-fix only, no risk.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
Remove the conditio
On Fri, 14 Feb 2025 02:23:40 GMT, SendaoYan wrote:
> Hi all,
>
> The newly added JMH tests
> 'org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark' fails
> "java.lang.NoClassDefFoundError: jdk/incubator/vector/Float16" by below test
> co
On Tue, 18 Feb 2025 09:58:50 GMT, SendaoYan wrote:
>> Hi all,
>>
>> The newly added JMH tests
>> 'org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark' fails
>> "java.lang.NoClassDefFoundError: jdk/incubator/vector/Float16" by
On Wed, 19 Feb 2025 20:04:33 GMT, Joe Wang wrote:
> The schema file is integral to the test, so we assume it will be present. A
> minor improvement would be to remove the conditional check that verifies its
> existence. This would allow the test to fail if it can't load the schema file.
Do you
On Wed, 19 Feb 2025 08:02:07 GMT, Claes Redestad wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use SetupCopyFiles macro to copy the dependency files
>
> If you have manually verified
On Fri, 14 Feb 2025 07:21:27 GMT, SendaoYan wrote:
> Hi all,
>
> Several JMH tests fails 'Cannot invoke "java.io.InputStream.available()"
> because "is" is null', because the file
> 'build/linux-x86_64-server-release/images/test/micro/benc
On Wed, 19 Feb 2025 08:02:07 GMT, Claes Redestad wrote:
> have manually verified that the build fails if any of these files are removed.
Yes. I have verified that. If I remove the dependency XML file, then `make
test-image CONF=release JOBS=1` will report below failure.
gmake[3]: *** No rule
On Wed, 19 Feb 2025 05:05:17 GMT, Claes Redestad wrote:
> If anyone changes these tests on the functional side we'd silently break.
After this PR, if the dependency XML files been removed will make `make
test-image` fails. So maybe we do not need a new unit test to guard it.
> Perhaps needs a
On Tue, 18 Feb 2025 20:18:12 GMT, Erik Joelsson wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use SetupCopyFiles macro to copy the dependency files
>
> make/test/BuildMicroben
-result/ ; time for test in `cat
> list.txt` ; do time make test TEST="micro:$test" MICRO="FORK=1;WARMUP_ITER=2"
> CONF=release &> build/jmh-result/$test.log ; done
>
>
> Change has been verified locally, no risk.
SendaoYan has updated the pull request in
On Tue, 18 Feb 2025 20:23:05 GMT, Erik Joelsson wrote:
> I'm not sure if this is the right way to solve this. I would really like
> someone more familiar with the microbenchmarks to weigh in on how this was
> originally meant to work.
Hi, @cl4es, Could you take took this PR.
-
PR
.org/browse/JDK-8343345). Change has been
> verified locally, test-fix only, no risk.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
Remove the extra whitespace
-
Changes:
- all: https://git.openjdk.org/jdk/pull/23624/files
On Tue, 18 Feb 2025 09:23:23 GMT, Andrey Turbanov wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove the extra whitespace
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/F
Hi all,
Test test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.java run passes
unexpectedly when missing the depentdent file
test/jaxp/javax/xml/jaxp/unittest/validation/CR6740048.xsd. This PR add a NULL
check after call `getResourceAsStream("CR6740048.xsd")`.
This PR do not change the or
Hi all,
The newly added JMH tests
'org.openjdk.bench.jdk.incubator.vector.VectorMultiplyOptBenchmark' fails
"java.lang.NoClassDefFoundError: jdk/incubator/vector/Float16" by below test
command:
make test MICRO="FORK=1;WARMUP_ITER=2"
TEST="micro:org.openjdk.bench.jdk.incubator.vector.VectorMu
On Thu, 13 Feb 2025 08:35:47 GMT, Nicole Xu wrote:
> As is suggested in
> [JDK-8342958](https://bugs.openjdk.org/browse/JDK-8342958), `jvmArgs` should
> be used consistently in microbenchmarks to 'align with the intuition that
> when you use jvmArgsAppend/-Prepend intent is to add to a set of
On Wed, 12 Feb 2025 08:27:22 GMT, Alan Bateman wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Set started as final
>
> Marked as reviewed by alanb (Reviewer).
Thanks @AlanBateman for
On Wed, 12 Feb 2025 03:24:07 GMT, SendaoYan wrote:
> Hi all,
>
> Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed
> unexpected without native library or with the incorrect native library path.
> The test command with incorrect native library path shows
ich with incorrect native
> library path, and we will seen this pass run timed out as expected.
>
> Change has been verified locally, test-fix only, no risk.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
Set started as fina
On Wed, 12 Feb 2025 08:21:04 GMT, Alan Bateman wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename latch to started, and do the countDown before the while loop
>
> tes
ich with incorrect native
> library path, and we will seen this pass run timed out as expected.
>
> Change has been verified locally, test-fix only, no risk.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
Rena
On Wed, 12 Feb 2025 07:15:58 GMT, Alan Bateman wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename latch to started, and do the countDown before the while loop
>
> tes
ich with incorrect native
> library path, and we will seen this pass run timed out as expected.
>
> Change has been verified locally, test-fix only, no risk.
SendaoYan has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes
On Wed, 12 Feb 2025 03:53:47 GMT, David Holmes wrote:
> Trivial fix for missing comma.
>
> Thanks
Thanks David. Apologize for mine carelessness.
-
PR Comment: https://git.openjdk.org/jdk/pull/23577#issuecomment-2652752680
On Wed, 12 Feb 2025 03:43:53 GMT, David Holmes wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove the additional check for virtual thread of
>> test/jdk/java/lang/Thread/virtual/T
Hi all,
Test test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java run passed
unexpected without native library or with the incorrect native library path.
The test command with incorrect native library path shows below. We will seen
this tests run passed unexpected before this PR, because th
On Tue, 11 Feb 2025 02:45:11 GMT, SendaoYan wrote:
> H all,
>
> This PR add `/native` keyword in the test header for virtual thread tests.
> The `/native` keyword will make run the related tests by jtreg standalone
> more friendly.
>
> I runed all the tests without -na
On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan wrote:
>> H all,
>>
>> This PR add `/native` keyword in the test header for virtual thread tests.
>> The `/native` keyword will make run the related tests by jtreg standalone
>> more friendly.
>>
>>
On Tue, 11 Feb 2025 09:03:24 GMT, SendaoYan wrote:
>> H all,
>>
>> This PR add `/native` keyword in the test header for virtual thread tests.
>> The `/native` keyword will make run the related tests by jtreg standalone
>> more friendly.
>>
>>
On Tue, 11 Feb 2025 09:00:46 GMT, SendaoYan wrote:
>> Can you remove this change from the PR as it this is a separate discussion?
>> My guess is that in your environment the Thread.yield is somehow taking more
>> than 5 seconds, is that right? In that case, we can modify
On Tue, 11 Feb 2025 08:53:41 GMT, Alan Bateman wrote:
>> Reason description as
>> https://github.com/openjdk/jdk/pull/23550#issuecomment-2650141187.
>
> Can you remove this change from the PR as it this is a separate discussion?
> My guess is that in your environment the Thread.yield is somehow
g time, such as
> java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native'
> keywork, jtreg will report 'Error. Use -nativepath to specify the location of
> native code' right away. So add the missing '/native' keyword will make run
>
On Tue, 11 Feb 2025 08:44:15 GMT, Alan Bateman wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java
>> tes
g time, such as
> java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native'
> keywork, jtreg will report 'Error. Use -nativepath to specify the location of
> native code' right away. So add the missing '/native' keyword will make run
> the t
On Tue, 11 Feb 2025 08:41:44 GMT, Alan Bateman wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add /native for test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java
>> tes
On Tue, 11 Feb 2025 07:30:49 GMT, Alan Bateman wrote:
> Can you check if these two needs to be updated too?
>
> test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java
> test/jdk/java/lang/Thread/virtual/Starvation.java
These two tests also need `/native` keyword.
- Test test/jdk/java/lang/T
g time, such as
> java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native'
> keywork, jtreg will report 'Error. Use -nativepath to specify the location of
> native code' right away. So add the missing '/native' keyword wil
g time, such as
> java/lang/Thread/virtual/JfrEvents.java. If we add the missing '/native'
> keywork, jtreg will report 'Error. Use -nativepath to specify the location of
> native code' right away. So add the missing '/native' keyword will make run
>
On Tue, 11 Feb 2025 07:26:04 GMT, Alan Bateman wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add --enable-native-access=ALL-UNNAMED for
>> test/jdk/java/lang/management/ThreadMXBe
H all,
This PR add `/native` keyword in the test header for virtual thread tests. The
`/native` keyword will make run the related tests by jtreg standalone more
friendly.
I runed all the tests without -nativepath argument and find the fail tests.
This will find all the virtual thread tests whi
On Wed, 5 Feb 2025 08:59:10 GMT, SendaoYan wrote:
> Hi all,
>
> This PR add `/native` keyword in the test header for FFM tests. The `/native`
> keyword will make run the related tests by jtreg standalone more friendly.
>
> I runed all the FFM tests without `-nativepath` arg
On Wed, 5 Feb 2025 08:59:10 GMT, SendaoYan wrote:
> Hi all,
>
> This PR add `/native` keyword in the test header for FFM tests. The `/native`
> keyword will make run the related tests by jtreg standalone more friendly.
>
> I runed all the FFM tests without `-nativepath` arg
Hi all,
This PR add `/native` keyword in the test header for FFM tests. The `/native`
keyword will make run the related tests by jtreg standalone more friendly.
I runed all the FFM tests without `-nativepath` argument and find the fail
tests. This will find all the FFM tests which missing '/nat
On Tue, 7 Jan 2025 15:14:18 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [4d8fb807](https://github.com/openjdk/jdk/commit/4d8fb80732fd17352c36254c6dfc1be5dbfbacf1)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to
On Tue, 7 Jan 2025 15:14:18 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [4d8fb807](https://github.com/openjdk/jdk/commit/4d8fb80732fd17352c36254c6dfc1be5dbfbacf1)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository to
On Mon, 3 Feb 2025 07:49:21 GMT, SendaoYan wrote:
> Hi all,
> The JMH test
> "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse"
> fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT'
> could not be parse
On Tue, 4 Feb 2025 02:40:59 GMT, SendaoYan wrote:
>> Hi all,
>> The JMH test
>> "org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse"
>> fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT'
>>
Hi all,
Several JMH tests fails "cannot access class jdk.internal.vm.ContinuationScope
(in module java.base) because module java.base does not export jdk.internal.vm
to unnamed module". This PR add VM option
`--add-exports=java.base/jdk.internal.vm=ALL-UNNAMED` to fix the JMH test bug.
Change
On Mon, 3 Feb 2025 22:18:51 GMT, Naoto Sato wrote:
> If we need more practical short name, "PST" might not be a bad choice.
I think use "Pacific Standard Time - PST" is a more practical chioce. The PR
has been updated.
-
PR Comment: https://git.openjdk.org/jdk/pull/23414#issuecomm
~/compiler-test/zzkk/TimeZoneTest.java
> Ecuador Time
> ECST
> ECT
>
>
> - Java 23 output:
>
>
> ~/software/jdk/temurin/jdk-23+37/bin/java
> ~/compiler-test/zzkk/TimeZoneTest.java
> Ecuador Time
> GMT-04:00
> GMT-05:00
>
>
> This PR use `Z` Time
On Mon, 3 Feb 2025 22:18:51 GMT, Naoto Sato wrote:
> most likely the failure was due to the removal of COMPAT locale provide
Yes. git bisect result shows that the failure was due to PR "8174269: Remove
COMPAT locale data provider from JDK"
And, use jdk22, the difference between '-Djava.locale
On Mon, 3 Feb 2025 04:16:57 GMT, SendaoYan wrote:
>> Hi all,
>> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on
>> linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform.
>> This PR add option '-XX:
On Sat, 1 Feb 2025 14:37:44 GMT, SendaoYan wrote:
> Hi all,
> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64.
> The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add
> option '-XX:+IgnoreUnrecogn
Hi all,
The JMH test
"org.openjdk.bench.java.time.format.ZonedDateTimeFormatterBenchmark.parse"
fails "java.time.format.DateTimeParseException: Text '2015:03:10:12:13:ECT'
could not be parsed at index 17".
The `ECT` standard for "America/Guayaquil" - "Ecuador Time", and since jdk23
the `ECT` Ti
n non
> x86_64 platform.
> Change has been verified locally, test-fix only, no risk.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
add missing ,
-
Changes:
- all: https://git.openjdk.org/jdk/pull/23409/files
-
On Mon, 3 Feb 2025 01:49:45 GMT, Hao Sun wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add missing ,
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/ColumnFilterBenchmark.ja
Hi all,
Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on linux-aarch64.
The VM option '-XX:UseAVX=2' only support on x86_64 platform. This PR add
option '-XX:+IgnoreUnrecognizedVMOptions' to make test run normally on non
x86_64 platform.
Change has been verified locally, test-fix o
On Wed, 4 Dec 2024 14:57:22 GMT, SendaoYan wrote:
> Hi all,
> The file src/java.base/share/native/libjli/java.c generate compile warning
> by gcc14 with gcc options `-fsanitize=undefined -O2`, and make jdk build
> error when configure with option `--enable-ubsan`. So I think it
On Mon, 16 Dec 2024 12:47:13 GMT, SendaoYan wrote:
>> Hi all,
>> The file src/java.base/share/native/libjli/java.c generate compile warning
>> by gcc14 with gcc options `-fsanitize=undefined -O2`, and make jdk build
>> error when configure with option `--enable
On Mon, 16 Dec 2024 12:47:13 GMT, SendaoYan wrote:
>> Hi all,
>> The file src/java.base/share/native/libjli/java.c generate compile warning
>> by gcc14 with gcc options `-fsanitize=undefined -O2`, and make jdk build
>> error when configure with option `--enable
1 - 100 of 263 matches
Mail list logo
