On Thu, 4 Nov 2021 13:10:37 GMT, Christian Stein wrote:
> This PR implements the fix as suggested by Adam Farley, which reads:
>
>> Note: Looks to be as simple as adding `jaccessinspector-32` and
>> `jaccesswalker-32` to `TOOLS_NOT_TO_TEST` at the top of
>> `HelpFlagsTest.java`, as the non-32b
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote:
> The lack of anything to compile in `syslookup.c` is leading to a number of
> issues in our tooling, on some architectures more than others (s390x seems to
> be the most problematic). They expect to be able to retrieve debuginfo and
On Thu, 4 Nov 2021 13:10:37 GMT, Christian Stein wrote:
> This PR implements the fix as suggested by Adam Farley, which reads:
>
>> Note: Looks to be as simple as adding `jaccessinspector-32` and
>> `jaccesswalker-32` to `TOOLS_NOT_TO_TEST` at the top of
>> `HelpFlagsTest.java`, as the non-32b
On Thu, 4 Nov 2021 04:19:02 GMT, Andrew John Hughes wrote:
> The lack of anything to compile in `syslookup.c` is leading to a number of
> issues in our tooling, on some architectures more than others (s390x seems to
> be the most problematic). They expect to be able to retrieve debuginfo and
On Mon, 1 Nov 2021 11:23:16 GMT, Aleksey Shipilev wrote:
> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
> giving failing intrinsics a second chance to match against the similar `Math`
> intrinsics. This has interesting consequence for matchers: we can
On Thu, 28 Oct 2021 08:47:31 GMT, Aleksey Shipilev wrote:
> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
> to call to runtime for a single memory barrier. We can simplify the native
On Mon, 1 Nov 2021 07:36:53 GMT, Aleksey Shipilev wrote:
>> `Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
>> `OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed
>> (useless?) to call to runtime for a single memory barrier. We can simplify
>
On Tue, 2 Nov 2021 06:25:33 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers
On Tue, 2 Nov 2021 06:25:33 GMT, Aleksey Shipilev wrote:
>> This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
>> giving failing intrinsics a second chance to match against the similar
>> `Math` intrinsics. This has interesting consequence for matchers
On Thu, 28 Oct 2021 08:58:48 GMT, Aleksey Shipilev wrote:
>> `Unsafe.storeStoreFence` currently delegates to stronger
>> `Unsafe.storeFence`. We can teach compilers to map this directly to already
>> existing rules that handle `MemBarStoreStore`. Like explicit
>> `Loa
On Wed, 27 Oct 2021 11:53:47 GMT, Aleksey Shipilev wrote:
> `Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`.
> We can teach compilers to map this directly to already existing rules that
> handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreF
On Mon, 1 Nov 2021 22:59:10 GMT, Vladimir Kozlov wrote:
> Yes, I am fine with new intrinsics for them.
All right, see new commit then.
-
PR: https://git.openjdk.java.net/jdk/pull/6184
24 ops/ms
> StrictMathBench.maxFloat thrpt4 230918.334 ± 63.160 ops/ms
> StrictMathBench.maxInt thrpt4 231059.128 ± 51.224 ops/ms
> StrictMathBench.maxLongthrpt4 194488.210 ± 495.224 ops/ms
>
> StrictMathBench.sqrtDouble thrpt4 231023.703 ± 247.33
On Mon, 1 Nov 2021 18:44:53 GMT, Vladimir Kozlov wrote:
> Removing intrinsics for StrictMatch `min/max` methods may prevent them from
> inlining if they are not hot when caller is compiled.
Would you like me to leave them instead? That would mean we introduce these new
intrinsic definitions:
On Thu, 28 Oct 2021 08:58:48 GMT, Aleksey Shipilev wrote:
>> `Unsafe.storeStoreFence` currently delegates to stronger
>> `Unsafe.storeFence`. We can teach compilers to map this directly to already
>> existing rules that handle `MemBarStoreStore`. Like explicit
>> `Loa
On Mon, 1 Nov 2021 13:08:05 GMT, Andrew Haley wrote:
> So we have _dsqrt and_dsqrt_strict, which must be functionally identical, but
> we provide both names because they're part of a public API. I think this
> deserves an explanatory comment in the code.
Yes, no problem, added comment near int
24 ops/ms
> StrictMathBench.maxFloat thrpt4 230918.334 ± 63.160 ops/ms
> StrictMathBench.maxInt thrpt4 231059.128 ± 51.224 ops/ms
> StrictMathBench.maxLongthrpt4 194488.210 ± 495.224 ops/ms
>
> StrictMathBench.sqrtDouble thrpt4 231023.703 ± 247.33
On Mon, 1 Nov 2021 07:32:18 GMT, Aleksey Shipilev wrote:
>> src/hotspot/share/classfile/vmIntrinsics.hpp line 526:
>>
>>> 524:do_name( storeFence_name,
>>> "storeFence")
This blocks JDK-8276215: `StrictMath` intrinsics are handled peculiarly by
giving failing intrinsics a second chance to match against the similar `Math`
intrinsics. This has interesting consequence for matchers: we can match the
native `StrictMath.sqrt` to non-native intrinsic for `Math.sqrt`. I
On Mon, 1 Nov 2021 02:15:04 GMT, David Holmes wrote:
> I'm not quite seeing the motivation here. Your claim is that the
> non-intrinsic implementations involve a native call and so that is too
> expensive; yet the new code still relies on the fullFence being intrinsified
> else it is still a n
On Mon, 1 Nov 2021 02:09:19 GMT, David Holmes wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Restore RN for fullFence
>
> src/hotspot/share/classfile/vmIntrinsics.hpp l
avgt3 0.406 ± 0.003 ns/op
> Single.release avgt3 15.838 ± 0.019 ns/op <--- upgraded, calls
> runtime
> Single.storeStore avgt3 15.844 ± 0.104 ns/op <--- upgraded, calls
> runtime
>
>
> Additional testing:
> - [x] Linux x86_64 fastde
On Thu, 28 Oct 2021 11:13:57 GMT, Aleksey Shipilev wrote:
> See the [integration
> commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30
> ) for JDK-8245095. It reintroduced `
On Thu, 28 Oct 2021 11:13:57 GMT, Aleksey Shipilev wrote:
> See the [integration
> commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30
> ) for JDK-8245095. It reintroduced `
See the [integration
commit](https://github.com/openjdk/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde#diff-5b9b15832385ab8e02ffca3ddef6d65a9dea73f45abbe5e4f0be561be02073ffR30
) for JDK-8245095. It reintroduced `java/util/stream` in
`exclusiveAccess.dirs`, which effectively reverts JDK-82479
On Thu, 28 Oct 2021 07:41:59 GMT, Aleksey Shipilev wrote:
>> Thanks for clarifying. Now we have all the intrinsics in place we have the
>> choice of delegating either at the Java level or the native level, where
>> previously we had to delegate at the Java level to get
avgt3 0.407 ± 0.039 ns/op
> Single.releaseFence avgt 3 0.406 ± 0.001 ns/op
> Single.storeStoreFence avgt3 0.406 ± 0.001 ns/op
>
>
> Additional testing:
> - [x] Linux x86_64 fastdebug `tier1`
Aleksey Shipilev has updated the
`Unsafe.{load|store}Fence` falls back to `unsafe.cpp` for
`OrderAccess::{acquire|release}Fence()`. It seems too heavy-handed (useless?)
to call to runtime for a single memory barrier. We can simplify the native
`Unsafe` interface by falling back to `fullFence` when `{load|store}Fence`
intrinsic
On Thu, 28 Oct 2021 07:23:52 GMT, David Holmes wrote:
>> Something should happen when intrinsic is disabled. Other fences have native
>> `Unsafe_{Load|Store|Full}Fence` entry points for this. We can, technically,
>> do the same here, but I see no need. Instead, we can fall back to the
>> alrea
On Thu, 28 Oct 2021 02:32:41 GMT, David Holmes wrote:
>> `Unsafe.storeStoreFence` currently delegates to stronger
>> `Unsafe.storeFence`. We can teach compilers to map this directly to already
>> existing rules that handle `MemBarStoreStore`. Like explicit
>> `LoadFence`/`StoreFence`, we intro
`Unsafe.storeStoreFence` currently delegates to stronger `Unsafe.storeFence`.
We can teach compilers to map this directly to already existing rules that
handle `MemBarStoreStore`. Like explicit `LoadFence`/`StoreFence`, we introduce
the special node to differentiate explicit fence and implicit s
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote:
> @prrace notices this here:
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think
> it is the already open issue that this patch is fixing. While the original
> patch added the test in `jdk_
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote:
> @prrace notices this here:
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think
> it is the already open issue that this patch is fixing. While the original
> patch added the test in `jdk_
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote:
> @prrace notices this here:
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think
> it is the already open issue that this patch is fixing. While the original
> patch added the test in `jdk_
On 10/1/21 4:46 PM, Brett Okken wrote:
The current pure Java implementation does two things: it provides a fallback
for pure-interpreter JVMs and it provides the reader with a simple
implementation.
I'm not at all sure we'd want a complex implementation.
I thought this might be the case.
Hav
On Thu, 30 Sep 2021 18:32:17 GMT, Alex Kasko wrote:
> I was working on backporting JDK-8268457 and found minor problems with the
> test introduced there:
>
> 1. `compareWith*` helper methods are used without `Assert.assertTrue()`
> wrapping, so they are effectively ignored
>
> 2. `this.getCla
On Fri, 1 Oct 2021 05:10:17 GMT, David Holmes wrote:
>> A regression introduced in Java 17 will give the default FJ pool a
>> parallelism of zero in a uniprocessor environment. The fix restores this to
>> a value of 1. See bug report for details.
>>
>> Testing:
>> - new regression test
>> -
On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote:
> Currently it fails with:
>
>
> $ CONF=linux-x86_64-server-fastdebug make run-test
> TEST=java/lang/management/MemoryMXBean/MemoryTest.java
>
> STDERR:
> java.lang.RuntimeException: TEST FAILED: Numb
On Wed, 29 Sep 2021 17:56:00 GMT, Aleksey Shipilev wrote:
> Currently it fails with:
>
>
> $ CONF=linux-x86_64-server-fastdebug make run-test
> TEST=java/lang/management/MemoryMXBean/MemoryTest.java
>
> STDERR:
> java.lang.RuntimeException: TEST FAILED: Numb
Currently it fails with:
$ CONF=linux-x86_64-server-fastdebug make run-test
TEST=java/lang/management/MemoryMXBean/MemoryTest.java
STDERR:
java.lang.RuntimeException: TEST FAILED: Number of heap pools = 1 but expected
<= 3 and >= 3
Z already handles it with a special configuration, Shenandoa
Fails like this:
$ CONF=linux-x86_64-server-fastdebug make run-test
TEST=java/lang/management/ManagementFactory/MXBeanException.java
TEST_VM_OPTS="-XX:+UseShenandoahGC"
...
java.lang.NullPointerException: Cannot invoke
"java.lang.management.MemoryPoolMXBean.setUsageThreshold(long)" because
@prrace notices this here:
https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think it
is the already open issue that this patch is fixing. While the original patch
added the test in `jdk_other`, Phil suggests it to be added to `jdk_desktop`.
Additional testing:
- [x] `jdk_
On Wed, 22 Sep 2021 23:19:50 GMT, Phil Race wrote:
> You'd need to add it to the desktop test group.
Right. See #5648.
-
PR: https://git.openjdk.java.net/jdk/pull/5544
On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote:
> This is a GUI test, and it should be `@headful`.
>
> Additional testing:
> - [x] Test still runs in default, and does not run with `!headful`
This pull request has now been integrated.
Changeset: 7acec3f1
Author:Alek
On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote:
> This is a GUI test, and it should be `@headful`.
>
> Additional testing:
> - [x] Test still runs in default, and does not run with `!headful`
Thank you!
-
PR: https://git.openjdk.java.net/jdk/pull/5544
On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev wrote:
> This is a GUI test, and it should be `@headful`.
>
> Additional testing:
> - [x] Test still runs in default, and does not run with `!headful`
Any takers? ;)
-
PR: https://git.openjdk.java.net/jdk/pull/5544
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote:
> As the follow-up for Zero-specific JDK-8273494, we might want to clean up
> build system logic for all VM variants: stop impersonating "server" VMs for
> all of them. This basically leaves "core" and &q
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote:
> As the follow-up for Zero-specific JDK-8273494, we might want to clean up
> build system logic for all VM variants: stop impersonating "server" VMs for
> all of them. This basically leaves "core" and &q
On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote:
> See the bug report for more details. I would appreciate if people with their
> corporate testing systems would run this through their systems to avoid
> surprises. (ping @RealCLanger, @iignatev).
This pull request has
On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev wrote:
> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
> @iignatev suggested to create tier4 groups that capture all tests not in
> tiers{1,2,3}.
>
> Caveats:
> - I excluded `applications` f
On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote:
> See the bug report for more details. I would appreciate if people with their
> corporate testing systems would run this through their systems to avoid
> surprises. (ping @RealCLanger, @iignatev).
Ok, let's try!
---
On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}.
>>
>> Caveats:
>> - I exclude
On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}.
>>
>> Caveats:
>> - I exclude
s 1110m43.704s
>
>
> There are interesting test failures on my machine, which I would address
> separately.
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/reb
On Thu, 16 Sep 2021 09:47:16 GMT, Jan Lahoda wrote:
>> This is a GUI test, and it should be `@headful`.
>>
>> Additional testing:
>> - [x] Test still runs in default, and does not run with `!headful`
>
> Ah, right, I thought it is a JShell test, but it is not. Sorry for the noise.
@lahodaj, wo
On Fri, 17 Sep 2021 05:47:20 GMT, Alan Bateman wrote:
> No objection from me. If issues arise then I assume it can be discussed again
> and we can figure out something that works for whatever CI or environment
> where it is problematic.
Yes, I think if tests start to fail, we look into concret
On Mon, 13 Sep 2021 19:57:14 GMT, Andrey Turbanov
wrote:
> 8273710: Remove redundant stream() call before forEach in jdk.jdeps
Marked as reviewed by shade (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5498
On Wed, 15 Sep 2021 15:09:45 GMT, Arno Zeller wrote:
>> See the bug report for more details. I would appreciate if people with their
>> corporate testing systems would run this through their systems to avoid
>> surprises. (ping @RealCLanger, @iignatev).
>
> I haven't recognized problems I can d
On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev wrote:
> As the follow-up for Zero-specific JDK-8273494, we might want to clean up
> build system logic for all VM variants: stop impersonating "server" VMs for
> all of them. This basically leaves "core" and &q
On Thu, 16 Sep 2021 09:39:25 GMT, Jan Lahoda wrote:
> Marking the test headful if OK - but should `headful` also be added to the
> keys in `test/langtools/TEST.ROOT`? (I am not quite sure how that works.)
AFAICS, this test is in `jdk`, so it is covered by `jdk/TEST.ROOT`. I tested it
with and
This is a GUI test, and it should be `@headful`.
Additional testing:
- [x] Test still runs in default, and does not run with `!headful`
-
Commit messages:
- Fix
Changes: https://git.openjdk.java.net/jdk/pull/5544/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5544&ra
On Wed, 15 Sep 2021 10:29:36 GMT, Aleksey Shipilev wrote:
> Happens with Zero tests:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
> TEST=compiler/codecache/CheckSegmentedCodeCache.java
> ...
>
> java.lang.NullPointerException: Cannot in
On Wed, 15 Sep 2021 10:29:36 GMT, Aleksey Shipilev wrote:
> Happens with Zero tests:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
> TEST=compiler/codecache/CheckSegmentedCodeCache.java
> ...
>
> java.lang.NullPointerException: Cannot in
On Wed, 15 Sep 2021 10:16:36 GMT, Aleksey Shipilev wrote:
> This currently manifests if you run Zero with compiler/codecache/cli tests
> (part of tier1):
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
> TEST=compiler/codecache/cli/
>
> STDERR:
>
On Wed, 15 Sep 2021 10:16:36 GMT, Aleksey Shipilev wrote:
> This currently manifests if you run Zero with compiler/codecache/cli tests
> (part of tier1):
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
> TEST=compiler/codecache/cli/
>
> STDERR:
>
On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` bec
On Wed, 15 Sep 2021 12:56:34 GMT, David Holmes wrote:
> Did you test building all variants into one image?
Yes, I did, but I think the build system is confused about the VM feature sets.
I have a vague recollection that ether @magicus or someone else at one point
suggested eliminating multi-va
Happens with Zero tests:
$ CONF=linux-x86_64-zero-fastdebug make exploded-test
TEST=compiler/codecache/CheckSegmentedCodeCache.java
...
java.lang.NullPointerException: Cannot invoke
"String.contains(java.lang.CharSequence)" because
"jdk.test.lib.Platform.compiler" is null
at jdk.test.lib.Plat
This currently manifests if you run Zero with compiler/codecache/cli tests
(part of tier1):
$ CONF=linux-x86_64-zero-fastdebug make exploded-test
TEST=compiler/codecache/cli/
STDERR:
java.lang.RuntimeException: Unknown VM mode.
at
jdk.test.lib.cli.CommandLineOptionTest.getVMTypeOption(Command
As the follow-up for Zero-specific JDK-8273494, we might want to clean up build
system logic for all VM variants: stop impersonating "server" VMs for all of
them. This basically leaves "core" and "custom" variants to be handled with
this patch.
Additional testing:
- [x] Linux x86_64 `core` bui
On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote:
> Currently, the build system defaults the libjvm.so location to "server".
> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
> need to see if moving the libjvm.so to a proper locat
On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev wrote:
> Currently, the build system defaults the libjvm.so location to "server".
> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
> need to see if moving the libjvm.so to a proper locat
On Fri, 10 Sep 2021 10:02:43 GMT, David Holmes wrote:
>> Currently, the build system defaults the libjvm.so location to "server".
>> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
>> need to see if moving the libjvm.so to a proper location breaks anything.
>>
>>
On Thu, 19 Aug 2021 15:15:31 GMT, Aleksey Shipilev wrote:
> See the bug report for more details. I would appreciate if people with their
> corporate testing systems would run this through their systems to avoid
> surprises. (ping @RealCLanger, @iignatev).
@ArnoZeller, have your runs
On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie wrote:
>> Currently, the build system defaults the libjvm.so location to "server".
>> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
>> need to see if moving the libjvm.so to a proper location breaks anything.
>>
On Thu, 9 Sep 2021 10:14:48 GMT, kabutz
wrote:
> …of MAX_PRIORITY-2 during refactoring
>
> Appears in Java 17 for the first time.
>
> During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to
> instead state Thread.MIN_PRIORITY - 2, which results in a negative priority,
>
On Thu, 9 Sep 2021 10:14:48 GMT, kabutz
wrote:
> …of MAX_PRIORITY-2 during refactoring
>
> Appears in Java 17 for the first time.
>
> During refactoring, the priority was changed from Thread.MAX_PRIORITY - 2 to
> instead state Thread.MIN_PRIORITY - 2, which results in a negative priority,
>
On Thu, 9 Sep 2021 15:12:27 GMT, Magnus Ihse Bursie wrote:
>> Ok, I agree. Can I do a Zero-specific thing here (so that it is potentially
>> cleanly backportable), and then handle the rest of the variants?
>
> Sure, that works for me.
While we are at it, do `core` and `custom` even carry their
On Thu, 9 Sep 2021 14:28:19 GMT, Magnus Ihse Bursie wrote:
>> Yes, there are at least "core" and "custom":
>>
>>
>> # All valid JVM variants
>> VALID_JVM_VARIANTS="server client minimal core zero custom"
>
> I think we should stop these as well from impersonating the server JVM.
> Preferably i
On Thu, 9 Sep 2021 13:02:23 GMT, David Holmes wrote:
>> Currently, the build system defaults the libjvm.so location to "server".
>> This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We
>> need to see if moving the libjvm.so to a proper location breaks anything.
>>
>> A
Currently, the build system defaults the libjvm.so location to "server". This
makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to
see if moving the libjvm.so to a proper location breaks anything.
Additional testing:
- [x] Linux x86_64 Zero build
- [x] Linux x86_64
On 9/9/21 2:36 PM, Kartik Ohri wrote:
I would like to work on a fix for JDK-8273541
Sure, it does not seem taken yet. Submit the PR, and work there.
--
Thanks,
-Aleksey
On Wed, 8 Sep 2021 13:25:27 GMT, Aleksey Shipilev wrote:
>> JDK-8179317 rewritten runtime shell tests to Java. There is a little
>> omission in VM variant selection, which makes Zero fail some of the tier1
>> tests, like:
>>
>>
>> $ CONF=linux-x86_
On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote:
> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission
> in VM variant selection, which makes Zero fail some of the tier1 tests, like:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613
On Wed, 8 Sep 2021 11:06:50 GMT, Arno Zeller wrote:
> Probably it could be a better solution to add the stress keyword for slow
> running or high load tests - like it is done in the hotspot part of the
> tests. Then automated test run can exclude or select these test by keyword.
Thought so too
On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote:
> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission
> in VM variant selection, which makes Zero fail some of the tier1 tests, like:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
rocessTools.createNativeTestProcessBuilder(ProcessTools.java:575)
>
>
>
> Additional testing:
> - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS)
> now run
Aleksey Shipilev has updated the pull request incrementally with one additional
commit
JDK-8179317 rewritten runtime shell tests to Java. There is a little omission
in VM variant selection, which makes Zero fail some of the tier1 tests, like:
$ CONF=linux-x86_64-zero-fastdebug make exploded-test
TEST=runtime/StackGap/TestStackGap.java
STDERR:
java.lang.Error: TESTBUG: unsupporte
On Tue, 7 Sep 2021 16:54:11 GMT, Alan Bateman wrote:
>> you are right about /manual being for GUI - but @AlanBateman pointed me at
>> few tests with libzip using it for similar reasons (e.g. long running tests).
>
> I don't think /manual is strictly UI but its usage is discouraged as manual
> t
==
> 00:12:21TEST TOTAL PASS
> FAIL ERROR
> 00:12:21jtreg:test/jdk/java/foreign/TestMatrix.java 3232
> 0 0
> 00:12:21 ==
>
> real 12m20.538s
> user 131m54.043s
> sys 0m59.9
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613
On Tue, 7 Sep 2021 15:04:31 GMT, Maurizio Cimadamore
wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can par
On Tue, 7 Sep 2021 14:30:41 GMT, Maurizio Cimadamore
wrote:
> So, what is the policy for defining developers tests that are not meant to be
> ran on every build infra, but are meant to be run on a more casual basis by
> developers working in a particular area? When we added TestMatrix we made
On Tue, 7 Sep 2021 14:05:46 GMT, Maurizio Cimadamore
wrote:
> if you still want to pursue the improvement, we can do that too.
Yes, I still want to pursue this test improvement.
-
PR: https://git.openjdk.java.net/jdk/pull/5358
On Tue, 7 Sep 2021 13:58:48 GMT, Maurizio Cimadamore
wrote:
> How is this test executed? I think when this was added the idea was that this
> had to be an advanced test which had to be run explicitly by users, but would
> not be picked up in the various test groups/tiers. I'm defo not seeing i
On Mon, 6 Sep 2021 13:22:03 GMT, Aleksey Shipilev wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` bec
On Sat, 4 Sep 2021 03:13:58 GMT, Igor Ignatyev wrote:
>>> > <...> I have excluded `vmTestbase` and `hotspot:tier4`<...> I have also
>>> > excluded `applications` from `hotspot:tier4` <...>
>>>
>>> assuming the goal of tier4 is to catch the rest of the tests, I don't think
>>> we should exclud
0 0
>
>jtreg:test/jaxp:tier4 0 0 0 0
>
> ==
>
> real 64m13.994s
> user 1462m1.213s
> sys 39m38.032s
>
>
> There are interesting test failures on my machine, which I would
0 0
>
>jtreg:test/jaxp:tier4 0 0 0 0
>
> ==
>
> real 64m13.994s
> user 1462m1.213s
> sys 39m38.032s
>
>
> There are interesting test failures on my machine, which I would
101 - 200 of 1073 matches
Mail list logo
