On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak wrote:
>> Improve the speed of Method.hashCode by caching the hashcode on first use.
>> I've seen an application where Method.hashCode is a hot path, and this is a
>> fairly simple speedup. The memory overhead is low.
>>
>> This addresses issue
On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee wrote:
> These 4 tests were failing due to an incompatibility with jcstress. They were
> problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
>
> Now that jcstress has been updated
> (https://github.com/openjdk/jdk/pull/19332) with
On Thu, 6 Jun 2024 12:46:36 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to
On Wed, 5 Jun 2024 14:56:26 GMT, jengebr wrote:
> clone() performs a shallow copy, so there is currently no Object[] allocated
> and therefore nothing to optimize.
Yes, I believe so.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1629666551
On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee wrote:
> These 4 tests were failing due to an incompatibility with jcstress. They were
> problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
>
> Now that jcstress has been updated
> (https://github.com/openjdk/jdk/pull/19332) with
On Mon, 3 Jun 2024 16:47:20 GMT, jengebr wrote:
> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
> cloning of Object[0] instances. This cloning is intended to prevent callers
> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
> to size
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 17:59:18 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 16:21:36 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but smany Methods have zero exceptions or zero
>> parameters,
On Tue, 21 May 2024 13:49:18 GMT, jengebr wrote:
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but smany Methods have zero exceptions or zero
> parameters, and
On Wed, 22 May 2024 14:32:23 GMT, Chen Liang wrote:
>> Thanks. Unfortunately the variable `cloneArray` is actually a method
>> parameter, and most of the callers pass in `false` - so using this utility
>> method to control cloning would actually introduce cloning in several places
>> where
On Wed, 22 May 2024 19:48:49 GMT, Chen Liang wrote:
>> I really see no reason to try and save on re-use of this one-line method for
>> _everything_. In fact, I do not quite see a very compelling reason to even
>> have the utility method. Sharing the code between `Method` and `Constructor`
>>
On Tue, 21 May 2024 13:49:18 GMT, jengebr wrote:
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but smany Methods have zero exceptions or zero
> parameters, and
On Fri, 26 Apr 2024 08:45:45 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #18690 for more details,
>>
On Wed, 24 Apr 2024 10:01:47 GMT, Claes Redestad wrote:
> > I really wish this change was not done with ClassFile API, but with a
> > simple bundled ASM, so it would be easily backportable, if we decide to. It
> > does not look like CFA buys us a lot here readability/complexity wise:
> >
On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>>
On Tue, 12 Mar 2024 18:42:48 GMT, Erik Joelsson wrote:
>> Chad Rakoczy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Code cleanup
>
> I'm fine with just using VERSION_FEATURE. I think it's a simple and
> straightforward enough
On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>>
On Tue, 12 Mar 2024 19:22:25 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>>
On Tue, 12 Mar 2024 23:44:45 GMT, Magnus Ihse Bursie wrote:
>> Chad Rakoczy has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Print to stdout instead of stderr
>> - Compare version using VERSION_STRING
>
>
On Tue, 12 Mar 2024 21:52:31 GMT, Elif Aslan wrote:
> This change enables to run JspawnhelperProtocol.java on MacOS.
>
> In addition to GHA , the test has been run on macos and linux.
>
>
> Test report is stored in
>
On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>>
On Mon, 11 Mar 2024 18:56:21 GMT, Bernd wrote:
> with a protocol version you don’t have to care about micro versions and also
> it is more tolerant about the usual cpu updates which do not introduce
> incompatibilities most of the time.
I think we can only reasonably guarantee that
On Mon, 11 Mar 2024 18:16:53 GMT, Erik Joelsson wrote:
> If you really want to require an exact match for jspawnhelper, then these 4
> numbers aren't necessarily enough, but a rather arbitrarily chosen
> approximation.
I think for our purposes, a version number quadruplet is enough to provide
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile
On Fri, 8 Mar 2024 07:35:27 GMT, Magnus Ihse Bursie wrote:
>> test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 29:
>>
>>> 27: * @test
>>> 28: * @bug 8325567
>>> 29: * @requires (os.family == "linux") | (os.family == "aix")
>>
>> Unless I'm mistaken, jspawn helper is used on
On Thu, 7 Mar 2024 20:04:13 GMT, Vladimir Petko wrote:
> I wonder if it would make sense to add a test with a correct argument format?
I would say that is what current jspawnhelper tests already test, and it is
also tested implicitly with `Process` tests. Let's keep this test for testing
that
On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
On Thu, 7 Mar 2024 16:29:12 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
On Thu, 7 Mar 2024 16:33:11 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make
On Tue, 5 Mar 2024 20:34:47 GMT, Vladimir Petko wrote:
> > The change in jspawnhelper looks good.
> > I think it would be simpler to have a separate
> > `jdk/java/lang/ProcessBuilder/JspawnhelperMisuse.java` test that simply
> > invokes the `jspawnhelper` and verifies the proper message is
On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan wrote:
> This change is intended to address the segmentation fault issue that occurs
> when jspawnhelper is called without arguments, and it includes an updated
> test to verify the behavior in such cases.
>
> Existing tests passes since it does not
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:
>
>
On Tue, 20 Feb 2024 20:58:50 GMT, Claes Redestad wrote:
> Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem
> out-of-place (not testing `StringBuffer`), redundant (covered by other tests
> like StringSubstring or the various String concatenation tests), or both.
> This
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
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
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
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
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
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
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
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
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?
>
>
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
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
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
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:
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
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
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,
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
>
> ==
> TEST FAI
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:
>
>>
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,
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:
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
>>
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
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
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
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:
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
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
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:
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
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
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
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
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
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
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
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
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
1 - 100 of 428 matches
Mail list logo
