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:
>
> , redundant (covered by other tests
> like StringSubstring or the various String concatenation tests), or both.
> This cle
On Tue, 20 Feb 2024 18:38:48 GMT, Claes Redestad wrote:
>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
>> StringBuilder/StringBuffer::toString returns `""` when the builders are
>> empty.
>>
>>
>> Name Cnt Base Error Test Er
On Tue, 20 Feb 2024 18:04:18 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/StringBuilder.java line 478:
>>
>>> 476: }
>>> 477: // Create a copy, don't share the array
>>> 478: return new String(this, null);
>>
>> Ok, this got me a bit confused, but
On Tue, 20 Feb 2024 18:00:42 GMT, Claes Redestad wrote:
>> test/micro/org/openjdk/bench/java/lang/StringBuffers.java line 49:
>>
>>> 47:
>>> 48: @Benchmark
>>> 49: public String emptyToString() {
>>
>> Do we actually need to remove the `substring` test here?
>
> I couldn't figure out w
On Tue, 20 Feb 2024 16:32:54 GMT, Claes Redestad wrote:
> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
> StringBuilder/StringBuffer::toString returns `""` when the builders are empty.
>
>
> Name Cnt Base Error Test Error Uni
On Tue, 13 Feb 2024 18:15:59 GMT, Dan Lutker wrote:
>> Just ignore the binary name and only check for argv1 is imho enough.
>
> I couldn't think if a better way to detect what the host system had and
> adding this seemed inline with the busybox check.
>
> The choice of running `sleep` seems li
On Fri, 9 Feb 2024 23:40:00 GMT, Dan Lutker wrote:
> Ran the test on AmazonLinux 2 which has multiple binaries from coreutils
> package and no coreutils executable as well as AmazonLinux 2023 that uses
> `--enable-single-binary`
test/jdk/java/lang/ProcessHandle/InfoTest.java line 321:
> 319:
On Tue, 6 Feb 2024 16:50:10 GMT, Paul Sandoz wrote:
> This pull request contains a backport of commit
> [1ae85138](https://github.com/openjdk/jdk/commit/1ae851387f881263ccc6aeace5afdd0f49d41d33)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being backported w
On Tue, 30 Jan 2024 09:08:28 GMT, Matthias Baesken wrote:
> On some Windows machines we see sometimes OOM errors because of high resource
> (memory/swap) consumption. This is especially seen when the jtreg runs have
> higher concurrency. A solution is to put the java/lang/StringBuilder tests in
On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev wrote:
> Some jtreg tests require resolvable external dependencies. This resolution is
> delegated to JIB, which is not used in vanilla OpenJDK testing. It would be
> convenient to add a keyword that marks tests that require these
On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev wrote:
> Some jtreg tests require resolvable external dependencies. This resolution is
> delegated to JIB, which is not used in vanilla OpenJDK testing. It would be
> convenient to add a keyword that marks tests that require these
On Thu, 25 Jan 2024 14:48:16 GMT, Maurizio Cimadamore
wrote:
> I don't 100% buy the `MethodHandleImpl` analogy. In that case the check is
> not simply used to save a branch, but to spare spinning of a completely new
> lambda form.
Doing this to save a few intructions would not likely to worth
On Wed, 24 Jan 2024 21:28:29 GMT, Leonid Mesnik wrote:
>> Some jtreg tests require resolvable external dependencies. This resolution
>> is delegated to JIB, which is not used in vanilla OpenJDK testing. It would
>> be convenient to add a keyword that marks tests that require these external
>>
On Wed, 24 Jan 2024 18:51:27 GMT, Maurizio Cimadamore
wrote:
> Naive question: the right way to use this would be almost invariably be like
> this:
>
> ```
> if (isCompileConstant(foo) && fooHasCertainStaticProperties(foo)) {
> // fast-path
> }
> // slow path
> ```
>
> Right?
Yes, I thi
On Wed, 24 Jan 2024 10:33:05 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch introduces `JitCompiler::isConstantExpression` which can be used
>> to statically determine whether an expression has been constant-folded by
>> the Jit compiler, leading to more constant-folding opportunities. For
On Wed, 24 Jan 2024 07:15:12 GMT, Quan Anh Mai wrote:
>> This seems really weird to me for Java code. The method doesn't get the
>> original "expression" it only gets the value of that expression after it has
>> been evaluated. Is there some kind of weird "magic" happening here?
>
> @dholmes-or
On Wed, 24 Jan 2024 15:20:37 GMT, Jie Fu wrote:
> This patch tries to fix the invalid test group definition of lib-test.
> Please review.
> Thanks.
Ooof. I wonder how that happened. This would not show up before we try to run
the actual libtest tests. What is extra wild is that GHA reports gree
On Tue, 23 Jan 2024 22:49:49 GMT, Quan Anh Mai wrote:
>> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 32:
>>
>>> 30: * Just-in-time-compiler-related queries
>>> 31: */
>>> 32: public class JitCompiler {
>>
>> An alternative name and location is `jdk.internal.vm.Constant
On Tue, 23 Jan 2024 22:41:44 GMT, Quan Anh Mai wrote:
>> src/java.base/share/classes/jdk/internal/misc/JitCompiler.java line 119:
>>
>>> 117: * @see #isCompileConstant(boolean)
>>> 118: */
>>> 119: @IntrinsicCandidate
>>
>> Note how the Java entry for MH intrinsic we have replaced
On Tue, 23 Jan 2024 16:01:05 GMT, Aleksey Shipilev wrote:
>> Would it be possible to list further examples where this might be used?
>> Asking because I'm wondering about the usability and maintainability of
>> if-then-else code.
>
>> Would it be possible to
On Tue, 23 Jan 2024 17:21:47 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch introduces `JitCompiler::isConstantExpression` which can be used
>> to statically determine whether an expression has been constant-folded by
>> the Jit compiler, leading to more constant-folding opportunities. For
On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev wrote:
>> Since recent work to improve `tier4` performance, we actually test
>> `tier{1,2,3,4}` often, which includes all the tests in current tree. It
>> would be more convenient to just have the `all` test group/alias, so
On Mon, 15 Jan 2024 11:05:09 GMT, Aleksey Shipilev wrote:
> Since recent work to improve `tier4` performance, we actually test
> `tier{1,2,3,4}` often, which includes all the tests in current tree. It would
> be more convenient to just have the `all` test group/alias, so that
On Tue, 23 Jan 2024 15:52:29 GMT, Alan Bateman wrote:
> Would it be possible to list further examples where this might be used?
> Asking because I'm wondering about the usability and maintainability of
> if-then-else code.
A similar thing is already used in JDK:
https://github.com/openjdk/jdk
On Tue, 23 Jan 2024 11:18:43 GMT, Quan Anh Mai wrote:
>> Hi,
>>
>> This patch introduces `JitCompiler::isConstantExpression` which can be used
>> to statically determine whether an expression has been constant-folded by
>> the Jit compiler, leading to more constant-folding opportunities. For
On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev wrote:
>> Since recent work to improve `tier4` performance, we actually test
>> `tier{1,2,3,4}` often, which includes all the tests in current tree. It
>> would be more convenient to just have the `all` test group/alias, so
On Tue, 23 Jan 2024 14:42:20 GMT, Roger Riggs wrote:
> Is there any place to document the new keyword or its usage; it does not seem
> very discoverable just existing in the TEST.ROOT and some tests.
I don't think there is a place to describe keywords, except in the relevant
`TEST.ROOT`-s.
--
On Tue, 23 Jan 2024 01:32:45 GMT, David Holmes wrote:
> Seems quite reasonable.
Thanks!
I shall wait for more reviewers, in case someone has an issue with
`external-dep` as the flag name.
-
PR Comment: https://git.openjdk.org/jdk/pull/17421#issuecomment-1905719123
On Tue, 23 Jan 2024 09:31:51 GMT, Quan Anh Mai wrote:
> Maybe I am ignorant but doesn't the definition of an intrinsics contain the
> signature of the method as well?
The definitions in `vmIntrinsics`, sure, they require full signature for
`@IntrinsicCandidate` methods. It would yield some unf
On Tue, 23 Jan 2024 08:16:07 GMT, Aleksey Shipilev wrote:
>> Hi,
>>
>> This patch introduces `JitCompiler::isConstantExpression` which can be used
>> to statically determine whether an expression has been constant-folded by
>> the Jit compiler, leading to more
On Tue, 23 Jan 2024 08:10:54 GMT, Quan Anh Mai wrote:
> Hi,
>
> This patch introduces `JitCompiler::isConstantExpression` which can be used
> to statically determine whether an expression has been constant-folded by the
> Jit compiler, leading to more constant-folding opportunities. For exampl
On Mon, 15 Jan 2024 10:48:23 GMT, Aleksey Shipilev wrote:
> Some jtreg tests require resolvable external dependencies. This resolution is
> delegated to JIB, which is not used in vanilla OpenJDK testing. It would be
> convenient to add a keyword that marks tests that require these
On Tue, 16 Jan 2024 09:01:35 GMT, Aleksey Shipilev wrote:
>> Since recent work to improve `tier4` performance, we actually test
>> `tier{1,2,3,4}` often, which includes all the tests in current tree. It
>> would be more convenient to just have the `all` test group/alias, so
On Tue, 16 Jan 2024 08:52:03 GMT, Alan Bateman wrote:
>> Tried not to introduce new `*_all` groups here. `jdk_all` would be the same
>> as `jdk:all`, TBH. But we still can do it for symmetry reasons, see new
>> commit.
>
> "all" looks okay but the comment "Catch-all" suggests something else,
>
11 0 <<
>jtreg:test/langtools:all 4469 4469 0 0
>
>jtreg:test/jaxp:all 513 513 0 0
>
>jtreg:test/lib-test:all 3232 0 0
>
> ==
>
On Mon, 15 Jan 2024 22:37:36 GMT, David Holmes wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> jdk_all and lib_test_all groups
>
> test/jdk/TEST.groups line 28:
>
>> 2
11 0 <<
>jtreg:test/langtools:all 4469 4469 0 0
>
>jtreg:test/jaxp:all 513 513 0 0
>
>jtreg:test/lib-test:all 3232 0 0
>
> ===
Since recent work to improve `tier4` performance, we actually test
`tier{1,2,3,4}` often, which includes all the tests in current tree. It would
be more convenient to just have the `all` test group/alias, so that we can do
`make test TEST=all`. This also gives a parallelism / run time benefit, a
On Fri, 12 Jan 2024 07:33:07 GMT, Sergey Bylokhov wrote:
> Just curious if this was found by inspection or when debugging some issue
> with LDAP authentication? Asking on whether it is feasible or not to have
> more tests in this area.
No need, that one is an easy target for static analyzers.
On Thu, 11 Jan 2024 06:28:51 GMT, Sergey Bylokhov wrote:
> SaslInputStream.read() should return a value in the range from 0 to 255 per
> the spec of InputStream.read() but it returns the signed byte from the inBuf
> as is.
Looks fine. I think the common style is to use capitalized `0xFF`, but
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
Marked as reviewed by shade (Reviewer).
-
PR Review: https://git.openjd
On Wed, 3 Jan 2024 21:29:57 GMT, Joshua Cao wrote:
>> ConcurrentHashMap's copy constructor calls `putAll()` -> `tryPresize()` ->
>> `transfer()`. When coming from the copy constructor, the Map is empty, so
>> there is nothing to transfer. But `transfer()` will still copy all the empty
>> nodes
On Fri, 15 Dec 2023 01:16:55 GMT, Joshua Cao wrote:
> ConcurrentHashMap's copy constructor calls `putAll()` -> `tryPresize()` ->
> `transfer()`. When coming from the copy constructor, the Map is empty, so
> there is nothing to transfer. But `transfer()` will still copy all the empty
> nodes fr
On Fri, 15 Dec 2023 01:16:55 GMT, Joshua Cao wrote:
> ConcurrentHashMap's copy constructor calls `putAll()` -> `tryPresize()` ->
> `transfer()`. When coming from the copy constructor, the Map is empty, so
> there is nothing to transfer. But `transfer()` will still copy all the empty
> nodes fr
On Wed, 6 Dec 2023 17:42:47 GMT, Brett Okken wrote:
>> The static AtomicInteger used for the nextHashCode should be final.
>
> Brett Okken has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update full name
@bokken, you are good to `/integrat
On Wed, 6 Dec 2023 00:52:48 GMT, Brett Okken wrote:
> The static AtomicInteger used for the nextHashCode should be final.
Looks okay to me!
Since this is new contribution, I would like someone else to take a look.
-
Marked as reviewed by shade (Reviewer).
PR Review: https://git.o
On Wed, 6 Dec 2023 00:52:48 GMT, Brett Okken wrote:
> The static AtomicInteger used for the nextHashCode should be final.
Submitted: https://bugs.openjdk.org/browse/JDK-8321470
Please change this PR title to "8321470: ThreadLocal.nextHashCode can be static
final", and bots would do the rest.
On 05.12.23 21:02, Brett Okken wrote:
Should the private static AtomicInteger nextHashCode also be final?
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ThreadLocal.java#L100
Yes, I think so. Feel free to submit a PR!
-Aleksey
Amazon Development Center Ger
On Thu, 30 Nov 2023 15:48:11 GMT, Jorn Vernee wrote:
> This test is problematic on Zero due to
> https://bugs.openjdk.org/browse/JDK-8321064
>
> Disable it for now on that platform, until a Zero maintainer has a chance to
> look into it.
>
> Testing: running TestHandshake on zero to see that
On Thu, 30 Nov 2023 16:18:42 GMT, Jorn Vernee wrote:
> > Hold on, can we figure out if Zero can actually be fixed before we go and
> > disable the test? I think we only disable the tests like this if there is
> > an intrinsic reason why the test does not apply to a platform.
>
> I would proble
On Thu, 30 Nov 2023 16:08:54 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList java/util/stream/GatherersTest.java.
All right! Hope it would be fixed soon. Trivial.
-
Marked as reviewed by shade (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/16909#pullreques
On Thu, 30 Nov 2023 15:48:11 GMT, Jorn Vernee wrote:
> This test is problematic on Zero due to
> https://bugs.openjdk.org/browse/JDK-8321064
>
> Disable it for now on that platform, until a Zero maintainer has a chance to
> look into it.
>
> Testing: running TestHandshake on zero to see that
On Wed, 29 Nov 2023 02:00:14 GMT, Joe Darcy wrote:
> Typo fix to to the new text added in JDK-8295391.
Marked as reviewed by shade (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/16872#pullrequestreview-1754814207
On Thu, 23 Nov 2023 03:14:27 GMT, David Holmes wrote:
>> As discussed in JBS all platforms (some tweaks to Zero are in progress)
>> actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip
>> out the locked-based alternatives to using it and just add a guarantee that
>> it i
On Wed, 22 Nov 2023 18:26:12 GMT, Daniel D. Daugherty
wrote:
>> src/hotspot/cpu/x86/vm_version_x86.cpp line 819:
>>
>>> 817: }
>>> 818:
>>> 819: _supports_cx8 = supports_cmpxchg8();
>>
>> I think we should leave the runtime check here (under `ifndef`, like in
>> ARM?). This covers the re
On Wed, 22 Nov 2023 08:57:11 GMT, Aleksey Shipilev wrote:
> Zero tests are running.
Caught the `guarantee` on linux-arm-zero-fastdebug! But that is actually the
fault in my previous patch: #16779.
-
PR Comment: https://git.openjdk.org/jdk/pull/16625#issuecomment-1822510325
On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes wrote:
>> As discussed in JBS all platforms (some tweaks to Zero are in progress)
>> actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip
>> out the locked-based alternatives to using it and just add a guarantee that
>> it i
On Wed, 22 Nov 2023 02:09:38 GMT, David Holmes wrote:
>> As discussed in JBS all platforms (some tweaks to Zero are in progress)
>> actually do support `cx8` i.e. 64-bit compare-and-exchange, so we can strip
>> out the locked-based alternatives to using it and just add a guarantee that
>> it i
On Tue, 21 Nov 2023 06:03:38 GMT, Erik Österlund wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary includes of vm_version.hpp.
>> Fix copyright years.
>
> This looks great!
> Thanks for the revi
On Tue, 14 Nov 2023 17:25:42 GMT, Darragh Clarke wrote:
>> Currently the `IsAlive` test occasionally times out.
>>
>> This PR changes the timeout from `10` to `25` which I think is an adequate
>> increase based on the failures I've seen. Though I'd be happy to change it
>> to another value if
On Mon, 13 Nov 2023 14:04:22 GMT, Stewart X Addison wrote:
>> ~~I will force push to change ONLY the commit message once I get a bug
>> created - I am not currently an author. In draft until I do that.~~ Done
>>
>> FYI @andrew-m-leonard (who I've discussed this with) and @GoeLin
>>
>> This fix
On Tue, 14 Nov 2023 13:10:50 GMT, Aleksey Shipilev wrote:
>> Stewart X Addison has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull re
On Mon, 13 Nov 2023 14:04:22 GMT, Stewart X Addison wrote:
>> ~~I will force push to change ONLY the commit message once I get a bug
>> created - I am not currently an author. In draft until I do that.~~ Done
>>
>> FYI @andrew-m-leonard (who I've discussed this with) and @GoeLin
>>
>> This fix
On Mon, 12 Jun 2023 17:28:44 GMT, Naoto Sato wrote:
>> One other thing to consider...
>> If the BaseLocale entries are being GC'd sooner, then perhaps the value of
>> the String.intern() is reduced.
>> Eliminating `.intern90` would make creating a normalized BaseLocale faster.
>
>> One other thi
On Wed, 25 Oct 2023 10:05:22 GMT, Jorn Vernee wrote:
>> The old code would throw `ShouldNotReachHere()` if we did not recognize the
>> handle type:
>> https://github.com/openjdk/jdk/blob/d2d1592dd94e897fae6fc4098e43b4fffb6d6750/src/hotspot/share/runtime/jniHandles.cpp#L207
>>
>> I think the new
On Wed, 25 Oct 2023 09:46:44 GMT, Jorn Vernee wrote:
>> src/hotspot/share/runtime/jniHandles.cpp line 202:
>>
>>> 200: ShouldNotReachHere();
>>> 201: }
>>> 202: } else if (is_local_handle(thread, handle) ||
>>> is_frame_handle(thread, handle)) {
>>
>> Should we still add `ShouldNot
On Mon, 23 Oct 2023 13:58:27 GMT, Jorn Vernee wrote:
> Explicitly handle UpcallStub allocation failures by terminating. We currently
> might try to use the returned `nullptr` which would fail sooner or later.
> This patch just makes the termination explicit.
Marked as reviewed by shade (Review
On Wed, 25 Oct 2023 09:54:14 GMT, Jorn Vernee wrote:
> I'll wait with this PR until we reach some conclusion.
I think we can proceed with this PR. The explicit failure is still better than
a failure somewhere downstream. That is, this PR does not change the failure
mode substantially, right? I
On Wed, 25 Oct 2023 09:41:33 GMT, Jorn Vernee wrote:
> But it sounds like you're saying that plain user code should never result in
> a VM error (if we can help it).
Yes, exactly. Granted, there are resource exhaustion situations where the
overall progress could be sluggish (e.g. if we near th
On Tue, 24 Oct 2023 17:01:35 GMT, Jorn Vernee wrote:
> The result of `FindClass` is a local JNI handle (in
> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we
> need to wrap the return value of `FindClass` in a global reference when
> storing it inside fallbackLinke
On Mon, 23 Oct 2023 13:58:27 GMT, Jorn Vernee wrote:
> Explicitly handle UpcallStub allocation failures by terminating. We currently
> might try to use the returned `nullptr` which would fail sooner or later.
> This patch just makes the termination explicit.
I find it pretty weird to terminate
On Tue, 17 Oct 2023 21:23:38 GMT, Aleksey Shipilev wrote:
> Recent regression, see bug. The fix is to use the proper `jlong <-> ptr`
> converters.
>
> Additional testing:
> - [x] Build now passes on ARM32
> - [x] Two affected JMH benchmarks still run
This p
On Wed, 18 Oct 2023 08:30:37 GMT, Aleksey Shipilev wrote:
>> Recent regression, see bug. The fix is to use the proper `jlong <-> ptr`
>> converters.
>>
>> Additional testing:
>> - [x] Build now passes on ARM32
>> - [x] Two affected JMH benchmarks
On Wed, 18 Oct 2023 03:54:17 GMT, Jorn Vernee wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use jlong.h
>
> test/micro/org/openjdk/bench/java/lang/foreign/libToCString.c line 2
> Recent regression, see bug. The fix is to use the proper `jlong <-> ptr`
> converters.
>
> Additional testing:
> - [x] Build now passes on ARM32
> - [x] Two affected JMH benchmarks still run
Aleksey Shipilev has updated the pull request incrementally with one addi
Recent regression, see bug. The fix is to use the proper `jlong <-> ptr`
converters.
Additional testing:
- [x] Build now passes on ARM32
- [x] Two affected JMH benchmarks still run
-
Commit messages:
- Fix
Changes: https://git.openjdk.org/jdk/pull/16228/files
Webrev: https://we
On Tue, 29 Aug 2023 20:00:49 GMT, Nikita Sakharin wrote:
>> `Collections.rotate` method contains a bug. This method throws
>> IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way
>> to reproduce:
>>
>> final int size = (1 << 30) + 1;
>> final List list = new ArrayList<>(s
On Tue, 29 Aug 2023 20:00:49 GMT, Nikita Sakharin wrote:
>> `Collections.rotate` method contains a bug. This method throws
>> IndexOutOfBoundsException on arrays larger than $2^{30}$ elements. The way
>> to reproduce:
>>
>> final int size = (1 << 30) + 1;
>> final List list = new ArrayList<>(s
On Thu, 14 Sep 2023 08:08:18 GMT, Soumadipta Roy wrote:
>> This test is running in tier1, and takes about 400 seconds to complete.
>> Thus, it drags the execution time of tier1 on large machines. The commit
>> includes changing the sequential run of test cases in
>> java/util/concurrent/tck/JS
On Fri, 8 Sep 2023 15:31:02 GMT, Aleksey Shipilev wrote:
> @RogerRiggs asked for this. The moves are mechanical, so nothing should be
> lost. Tell me if other things need to be sorted as well.
>
> I would wait a little to see if there are any more JDK-8304913 followups.
This pull
On Fri, 8 Sep 2023 15:31:02 GMT, Aleksey Shipilev wrote:
> @RogerRiggs asked for this. The moves are mechanical, so nothing should be
> lost. Tell me if other things need to be sorted as well.
>
> I would wait a little to see if there are any more JDK-8304913 followups
On Fri, 8 Sep 2023 15:31:02 GMT, Aleksey Shipilev wrote:
> @RogerRiggs asked for this. The moves are mechanical, so nothing should be
> lost. Tell me if other things need to be sorted as well.
>
> I would wait a little to see if there are any more JDK-8304913 followups.
Any o
@RogerRiggs asked for this. The moves are mechanical, so nothing should be
lost. Tell me if other things need to be sorted as well.
I would wait a little to see if there are any more JDK-8304913 followups.
-
Commit messages:
- Fix
Changes: https://git.openjdk.org/jdk/pull/15640/fi
On Mon, 4 Sep 2023 07:26:37 GMT, Aleksey Shipilev wrote:
> Similar to other issues in the same area. I have no PPC32 machine to test the
> build on, but this matches other fixes for other architectures
> (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb)
On Thu, 7 Sep 2023 16:21:18 GMT, Aleksey Shipilev wrote:
>> Similar to other issues in the same area. I have no PPC32 machine to test
>> the build on, but this matches other fixes for other architectures
>> (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc6
On Thu, 7 Sep 2023 13:54:25 GMT, Martin Doerr wrote:
>> 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/rebase. The pull request contain
On Thu, 7 Sep 2023 14:07:05 GMT, Roger Riggs wrote:
>> 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/rebase. The pull request contain
On Thu, 7 Sep 2023 14:07:05 GMT, Roger Riggs wrote:
>> 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/rebase. The pull request contain
On Thu, 7 Sep 2023 13:51:31 GMT, Aleksey Shipilev wrote:
>> Similar to other issues in the same area. I have no PPC32 machine to test
>> the build on, but this matches other fixes for other architectures
>> (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc6
> Similar to other issues in the same area. I have no PPC32 machine to test the
> build on, but this matches other fixes for other architectures
> (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb)
> after this fix the PPC32 Zero build completes fi
On Thu, 7 Sep 2023 12:45:14 GMT, Martin Doerr wrote:
>> Yeah, we can technically change to `PPC32`. But the current thing follows
>> what build system uses as `OPENJDK_TARGET_CPU` (`ppc`) and what would be
>> used as `os.arch` because of that. So, choosing which way to deviate:
>> towards buil
> Similar to other issues in the same area. I have no PPC32 machine to test the
> build on, but this matches other fixes for other architectures
> (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb)
> after this fix the PPC32 Zero build completes fi
On Mon, 4 Sep 2023 19:54:46 GMT, Martin Doerr wrote:
>> Similar to other issues in the same area. I have no PPC32 machine to test
>> the build on, but this matches other fixes for other architectures
>> (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb)
>> after t
On Mon, 4 Sep 2023 07:28:03 GMT, Aleksey Shipilev wrote:
> Similar to other issues in the same area. I have no SPARC machine to test the
> build on, but this matches other fixes for other architectures
> (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb)
On Mon, 4 Sep 2023 07:28:03 GMT, Aleksey Shipilev wrote:
> Similar to other issues in the same area. I have no SPARC machine to test the
> build on, but this matches other fixes for other architectures
> (https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb)
Similar to other issues in the same area. I have no SPARC machine to test the
build on, but this matches other fixes for other architectures
(https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb)
after this fix the SPARC Zero build completes fine.
-
Commit
Similar to other issues in the same area. I have no PPC32 machine to test the
build on, but this matches other fixes for other architectures
(https://github.com/openjdk/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb)
after this fix the PPC32 Zero build completes fine.
-
Commit
On Wed, 23 Aug 2023 13:45:14 GMT, Matthias Baesken wrote:
> There seems to be a codepath in
> Java_java_util_prefs_FileSystemPreferences_lockFile0 where the errno is not
> stored but potentially accessed in the calling Java code.
Looks reasonable.
-
Marked as reviewed by shade (R
On Wed, 23 Aug 2023 16:41:23 GMT, Alan Bateman wrote:
> If yielding fails due to the pinning then VirtualThread.parkNanos parks on
> the carrier thread with the remaining time. The calculation of the remaining
> time needs to be replaced so that it obviously uses the difference between
> the s
201 - 300 of 598 matches
Mail list logo
