On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong wrote:
> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a
> != 0 ? a : b`", which can be implemented with existing APIs like "`compare +
> blend`". The current implementation is more complex especially for the
>
On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong wrote:
> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a
> != 0 ? a : b`", which can be implemented with existing APIs like "`compare +
> blend`". The current implementation is more complex especially for the
>
> Revised test to check and close all of the streams used in the pipeline.
>
> The test now checks the content length and closes each stdout and stderr
> stream.
>
> The previous technique to redirect stderr to stdout was ineffective because
> the fd/stream was still created in the parent
On Fri, 19 Aug 2022 17:05:38 GMT, Roger Riggs wrote:
> On Mac OS X on aarch64, the timing of the sysctl vs the process life (pid)
> can be such that the sysctl returns EIO.
> The native implementation is modified to treat EIO the same as EINVAL,
> leaving the information to be returned empty.
On 8/22/2022 11:57 AM, Alan Bateman wrote:
On 22/08/2022 18:13, Kasper Nielsen wrote:
Hi,
I understand that the methods are behaving as specified.
However, I still think that
int.class.getPackageName() = "java.lang"
int.class.describeConstable().get().packageName() = ""
is surprising
On Mon, 22 Aug 2022 18:03:21 GMT, Daniel D. Daugherty
wrote:
>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>>
>> I couldn't
On Fri, 19 Aug 2022 19:48:24 GMT, Daniel D. Daugherty
wrote:
>> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG
>> setting
>> when waiting for a compilation to finish.
>>
>> This fix is being tested in my jdk-20+10 stress testing run.
>>
>> The usual Mach5
On Thu, 11 Aug 2022 20:09:06 GMT, Daniel D. Daugherty
wrote:
> Split the java/util/stream/SpinedBufferTest.java test into two parts:
> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>
> I couldn't
On Thu, 11 Aug 2022 20:02:06 GMT, Daniel D. Daugherty
wrote:
> A trivial fix so that Continuation/Fuzz.java honors the timeoutFactor JTREG
> setting
> when waiting for a compilation to finish.
>
> This fix is being tested in my jdk-20+10 stress testing run.
>
> The usual Mach5 timeoutFactor
On Mon, 22 Aug 2022 18:59:33 GMT, Roger Riggs wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> shipilev CR changes
>
> LGTM
@RogerRiggs - Thanks for the re-review!
-
PR:
On Mon, 22 Aug 2022 18:03:21 GMT, Daniel D. Daugherty
wrote:
>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>>
>> I couldn't
On 22/08/2022 18:13, Kasper Nielsen wrote:
Hi,
I understand that the methods are behaving as specified.
However, I still think that
int.class.getPackageName() = "java.lang"
int.class.describeConstable().get().packageName() = ""
is surprising behavior. And should probably as a minimum be
On Fri, 19 Aug 2022 17:05:38 GMT, Roger Riggs wrote:
> On Mac OS X on aarch64, the timing of the sysctl vs the process life (pid)
> can be such that the sysctl returns EIO.
> The native implementation is modified to treat EIO the same as EINVAL,
> leaving the information to be returned empty.
On Mon, 22 Aug 2022 18:04:30 GMT, Aleksey Shipilev wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> shipilev CR changes
>
> I am good with this version, thanks.
@shipilev - Thanks for the very fast
On Mon, 22 Aug 2022 18:03:21 GMT, Daniel D. Daugherty
wrote:
>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>>
>> I couldn't
> Split the java/util/stream/SpinedBufferTest.java test into two parts:
> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>
> I couldn't figure out a way to set a larger timeout value for the entirety
> of
On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev wrote:
>> We have a few reports that existing Weak* VarHandle tests are still flaky,
>> for example on large AArch64 machines or small RISC-V machines.
>>
>> The flakiness is intrinsic to the nature of Weak* operations under tests,
>> that
On Mon, 22 Aug 2022 07:35:28 GMT, Aleksey Shipilev wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Refactor SpinedBufferTest.java by type.
>
>
On Mon, 22 Aug 2022 07:42:06 GMT, Aleksey Shipilev wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Refactor SpinedBufferTest.java by type.
>
> Looks much better, I have only a few Java stylistic nits.
Hi,
I understand that the methods are behaving as specified.
However, I still think that
int.class.getPackageName() = "java.lang"
int.class.describeConstable().get().packageName() = ""
is surprising behavior. And should probably as a minimum be
documented on ClassDesc::packageName.
/Kasper
On
On Mon, 22 Aug 2022 16:49:34 GMT, Martin Doerr wrote:
> My concern is that we may not notice implementation problems any more when
> retrying so often. Accidental cache line sharing should better get fixed in
> the tests if possible. Context switching or cache capacity limits may cause 1
>
On Mon, 22 Aug 2022 13:36:43 GMT, Aleksey Shipilev wrote:
> > In general, I appreciate making these tests more resilient. However, I
> > wonder about such large numbers for retry attempts. Smells like more than
> > just sporadic failures. Are we sure there is no bug which causes more
> >
Hello,
The method Class.getPackage is behaving as specified:
public Package getPackage()
Gets the package of this class.
If this class represents an array type, a primitive type or void, this
method returns null.
as is Class.getPackageName():
If this class represents an array type then
> Please review the change to update to using jtreg 7.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `requiredVersion` has been updated in the various `TEST.ROOT`
> files.
On Fri, 19 Aug 2022 16:32:02 GMT, Naoto Sato wrote:
> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a
> `reset()` call to the decoder seeing the EOF before the last `decode()`
> operation to handle the state correctly. Removing the call should not affect
> other cases
On Fri, 29 Jul 2022 03:55:54 GMT, Xiaohong Gong wrote:
> Vector API binary op "`FIRST_NONZERO`" represents the vector operation of "`a
> != 0 ? a : b`", which can be implemented with existing APIs like "`compare +
> blend`". The current implementation is more complex especially for the
>
On Fri, 19 Aug 2022 15:41:47 GMT, Alexey Semenyuk wrote:
> Get rid of dependencies on specific jtreg's jars from jpackage junit tests.
>
> The troublesome statement was `* @library ${jtreg.home}/lib/junit.jar
> ${jtreg.home}/lib/hamcrest.jar` in "junit.java". The fix removes "junit.java"
>
On Mon, 22 Aug 2022 13:12:25 GMT, Martin Doerr wrote:
> In general, I appreciate making these tests more resilient. However, I wonder
> about such large numbers for retry attempts. Smells like more than just
> sporadic failures. Are we sure there is no bug which causes more failures?
> Does
On Fri, 19 Aug 2022 14:16:32 GMT, Eric Caspole wrote:
> These changes reduce the run time from about 3h15m to about 2h5m.
This pull request has now been integrated.
Changeset: e5619339
Author:Eric Caspole
URL:
On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev wrote:
>> We have a few reports that existing Weak* VarHandle tests are still flaky,
>> for example on large AArch64 machines or small RISC-V machines.
>>
>> The flakiness is intrinsic to the nature of Weak* operations under tests,
>> that
On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev wrote:
>> We have a few reports that existing Weak* VarHandle tests are still flaky,
>> for example on large AArch64 machines or small RISC-V machines.
>>
>> The flakiness is intrinsic to the nature of Weak* operations under tests,
>> that
On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `requiredVersion`
On Sun, 21 Aug 2022 23:19:16 GMT, Naoto Sato wrote:
>> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a
>> `reset()` call to the decoder seeing the EOF before the last `decode()`
>> operation to handle the state correctly. Removing the call should not affect
>> other
On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev wrote:
>> We have a few reports that existing Weak* VarHandle tests are still flaky,
>> for example on large AArch64 machines or small RISC-V machines.
>>
>> The flakiness is intrinsic to the nature of Weak* operations under tests,
>> that
On Fri, 19 Aug 2022 18:14:16 GMT, Aleksey Shipilev wrote:
>> We have a few reports that existing Weak* VarHandle tests are still flaky,
>> for example on large AArch64 machines or small RISC-V machines.
>>
>> The flakiness is intrinsic to the nature of Weak* operations under tests,
>> that
On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `requiredVersion`
Hi,
I was playing around with java.lang.constant and found an inconsistency between
ClassDesc::packageName and Class::getPackageName as outlined in the table below.
Specifically dealing with primitive and array types.
Class ClassDesc::packageName Class::getPackage Class::getPackageName
> The symbolic constants API (`java.lang.constant`) was designed, in part, to
> provide bytecode parsing and generation APIs with a validated, common,
> symbolic form for constants in Java class files.
>
> There is an easy way to create a `ClassDesc` from a binary name
> (`ClassDesc::of`) or
On Sat, 20 Aug 2022 02:41:50 GMT, Daniel D. Daugherty
wrote:
>> Split the java/util/stream/SpinedBufferTest.java test into two parts:
>> - java/util/stream/SpinedBufferTest1.java has the first 6 test cases
>> - java/util/stream/SpinedBufferTes2.java has the second 6 test cases
>>
>> I couldn't
On Tue, 26 Jul 2022 09:25:48 GMT, Maurizio Cimadamore
wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> updated ClassDesc::ofInternal javadoc with JVMS link and fixed indentation
>
>
On Tue, 26 Jul 2022 19:57:38 GMT, ExE Boss wrote:
>> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 85:
>>
>>> 83: * given the name of the class or interface in internal form,
>>> 84: * such as {@code "java/lang/String"}.
>>> 85: * (To create a descriptor for
On Sun, 21 Aug 2022 23:19:16 GMT, Naoto Sato wrote:
>> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a
>> `reset()` call to the decoder seeing the EOF before the last `decode()`
>> operation to handle the state correctly. Removing the call should not affect
>> other
42 matches
Mail list logo
