Hello,
After much more thorough analysis of benchmarks on different platforms I
tend to cancel this patch proposal.
As Brian rightly remarked [3], the benchmark has peculiar explicit
iteration over the data. This is more like 2nd anti-pattern in safe
looping JMH sample [4]. This actually cam
d) zero is present at that point
in the code.
-Joe
On 7/10/2020 11:11 AM, Dmitry Chuyko wrote:
Hello,
Please review a small change in Math.signum(double d) and
Math.signum(float f) that improves performance for positive and
negative numbers.
Current version first checks if the number is NaN or
Hello,
Please review a small change in Math.signum(double d) and
Math.signum(float f) that improves performance for positive and negative
numbers.
Current version first checks if the number is NaN or zero, and for all
other numbers it extracts sign bit and constructs fp result. That makes
a
On 8/20/19 11:02 AM, Andrew Dinn wrote:
On 19/08/2019 19:38, Dmitry Chuyko wrote:
Just a minor style thing in MapSyncFail test: can "true" and "false"
(the mode) be "READ_WRITE_SYNC" and "READ_ONLY_SYNC" instead?
Are you referring to the arguments pa
Hi Andrew,
Just a minor style thing in MapSyncFail test: can "true" and "false"
(the mode) be "READ_WRITE_SYNC" and "READ_ONLY_SYNC" instead?
-Dmitry
On 8/19/19 2:29 PM, Andrew Dinn wrote:
Hi Alan,
...
I renamed the test to MapSyncFail and modified it to run without
restrict
On 8/7/19 4:29 PM, Andrew Dinn wrote:
On 07/08/2019 13:04, Dmitry Chuyko wrote:
On 8/7/19 2:02 PM, Dmitry Chuyko wrote:
Andrew,
New code is buildable and new MapFail test passes on different
platforms except it fails on linux i386:
Ah, that even was x86_64 (sorry, mixed up results from
/sun.nio.ch.FileChannelImpl.map0(Native Method)
at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1062)
at MapFail.main(MapFail.java:48)
... 6 more
-Dmitry
On 8/7/19 3:04 PM, Dmitry Chuyko wrote:
On 8/7/19 2:02 PM, Dmitry Chuyko wrote:
Andrew,
New code is buildable and new MapFail test passes on
On 8/7/19 2:02 PM, Dmitry Chuyko wrote:
Andrew,
New code is buildable and new MapFail test passes on different
platforms except it fails on linux i386:
Ah, that even was x86_64 (sorry, mixed up results from automated
system). I'll try to reproduce it by hand to see if there ar
": " before actual
unexpected message.
-Dmitry
On 8/7/19 12:31 PM, Dmitry Chuyko wrote:
On 8/6/19 6:58 PM, Andrew Dinn wrote:
..
No this behaviour is not currently tested. However, the only client at
present will never exercise that path so it is not critical to test it
n
On 8/6/19 7:09 PM, Andrew Dinn wrote:
Hello Dmitry,
On 06/08/2019 15:25, Dmitry Chuyko wrote:
One quick question about synchronization in unmappers. One of
preliminary steps for Loom was to replace monitor usage by j.u.c locks
for I/O to let fibers release carrier threads. For instance see
JDK
On 8/6/19 6:58 PM, Andrew Dinn wrote:
..
No this behaviour is not currently tested. However, the only client at
present will never exercise that path so it is not critical to test it
now. I'd be happy to address testing of this behaviour as part of a
follow-up JIRA issue if yo
Hi Andrew,
Thanks for previous detailed explanations, and great, there are now
checks for exceptions in webrev.11. Let me add just a few comments about
that.
On 8/1/19 12:49 PM, Andrew Dinn wrote:
Hello Dmitry,
On 01/08/2019 05:09, Dmitry Chuyko wrote:
Just a small comment about the tests
Hi Andrew,
One quick question about synchronization in unmappers. One of
preliminary steps for Loom was to replace monitor usage by j.u.c locks
for I/O to let fibers release carrier threads. For instance see
JDK-8222774. Does it make sense to do the same in your new unmappers code?
-Dmitry
Hi Andrew,
Just a small comment about the tests. As you can see, some of tests in
jdk/java/nio/channels/FileChannel check various modes, arguments, and
expected exceptions. E.g. see MapTest, Mode and Args.
I noticed that in your changes for the new map mode there are new
exceptions thrown in
Hello,
Please review a tiny fix of a test bug that appears in some
environments. While extending jpackage platforms support in JDK-8222778
I used "-E" rpmbuild shortcut for arch detection. It seems to be missing
in some versions while full "--eval" flag name is more generic.
bug: https://bug
DK-8228402.
-Dmitry
On 7/25/19 12:56 AM, Alexander Matveev wrote:
Looks good.
On 7/24/2019 7:30 AM, Dmitry Chuyko wrote:
Webrev without chdir() and write() changes:
http://cr.openjdk.java.net/~dchuyko/8222778/webrev.03/
When it is applied together with webrev.01 [1] from JDK-8228402,
sandbox i
/~herrick/8228402/
On 7/19/19 11:31 AM, Andrew Haley wrote:
On 7/19/19 12:36 AM, Dmitry Chuyko wrote:
On 7/18/19 11:57 AM, Andrew Haley wrote:
Hi,
On 7/17/19 10:19 PM, Dmitry Chuyko wrote:
On 7/17/19 11:52 AM, Andrew Haley wrote:
This is weird:
--- old/src/jdk.jpackage/linux/native
On 7/18/19 11:57 AM, Andrew Haley wrote:
Hi,
On 7/17/19 10:19 PM, Dmitry Chuyko wrote:
On 7/17/19 11:52 AM, Andrew Haley wrote:
This is weird:
--- old/src/jdk.jpackage/linux/native/libapplauncher/LinuxPlatform.cpp
2019-07-16 22:11:30.200258978 +0300
+++ new/src/jdk.jpackage/linux/native
On 7/18/19 12:19 AM, Dmitry Chuyko wrote:
..
2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is
still
mapped to i386, and other archs map to themselves.
3. In tests, new method getRpmArch() was added to linux/base/Base.java,
it maps JVMs os.arch to default
Hi Andrew,
On 7/17/19 11:52 AM, Andrew Haley wrote:
On 7/16/19 8:55 PM, Dmitry Chuyko wrote:
Hello,
Please review a small patch that mostly fixes jpackage test for Linux
aarch64 and also arm,x86,power. It is prepared for 'JDK-8200758-branch'
branch of open 'sandbox' repo.
, Dmitry Chuyko wrote:
Alexander, thanks for having a look,
On 7/17/19 12:30 AM, Alexander Matveev wrote:
Hi Dmitry,
http://cr.openjdk.java.net/~dchuyko/8222778/webrev.00/src/jdk.jpackage/unix/native/libapplauncher/PosixPlatform.cpp.frames.html
Why code between lines 215 and 219 was disabled
55 PM, Dmitry Chuyko wrote:
Hello,
Please review a small patch that mostly fixes jpackage test for Linux
aarch64 and also arm,x86,power. It is prepared for
'JDK-8200758-branch' branch of open 'sandbox' repo.
There are few parts:
1. LinuxPlatform.cpp and IniFile.cpp got
Hello,
Please review a small patch that mostly fixes jpackage test for Linux
aarch64 and also arm,x86,power. It is prepared for 'JDK-8200758-branch'
branch of open 'sandbox' repo.
There are few parts:
1. LinuxPlatform.cpp and IniFile.cpp got small fixes for compiler warnings.
2. LinuxDebBun
Thanks for the review, pushed with copyright update.
-Dmitry
On 5/22/19 8:36 PM, Roger Riggs wrote:
Hi Dmitry,
Looks ok.
Roger
On 05/21/2019 04:24 PM, Dmitry Chuyko wrote:
Hello,
Please review a small fix for compilation error reported by recent
compiler in canonicalize() from
Hello,
Please review a small fix for compilation error reported by recent compiler in
canonicalize() from canonicalize_md.c. PATH_MAX may be passed as num argument
to strncpy() and ‘\0’ is added to resulting string. The case of too long name
is processed at the beginning of canonicalize() so du
Thanks for all the reviews.
mach5-one-dchuyko-JDK-8215009-4-20190226-2029-850647: PASSED.
Pushed.
-Dmitry
On 2/27/19 12:07 AM, David Holmes wrote:
Hi Dmitry,
This seems fine to me too - much simpler.
Thanks,
David
On 27/02/2019 6:23 am, Dmitry Chuyko wrote:
I made mentioned cleanups in
y not the place to fix it and it is locally
consistent.
Thanks, Roger
On 02/25/2019 01:16 PM, Mikael Vidstedt wrote:
On Feb 25, 2019, at 9:09 AM, Dmitry Chuyko
wrote:
On 2/22/19 9:55 PM, Roger Riggs wrote:
Hi,
After a closer look, I'd take the route of the 01 webrev.
It is more loc
n Feb 21, 2019, at 9:55 AM, Dmitry Chuyko
wrote:
To me thread function wrappers look preferable to platform
specific JavaMain signature. Consider this webrev with wrappers:
http://cr.openjdk.java.net/~dchuyko/8215009/webrev.01/
In some cases JavaMain is called in the same thread and its resu
:56 am, Dmitry Chuyko wrote:
On 12/18/18 3:39 AM, David Holmes wrote:
On 11/12/2018 9:30 pm, Dmitry Chuyko wrote:
On 12/11/18 4:03 AM, David Holmes wrote:
Hi Dmitry,
On 11/12/2018 12:16 am, Dmitry Chuyko wrote:
Hello,
Please review a small fix in java_md_solinux.c: continuation is
not truly
On 12/18/18 3:39 AM, David Holmes wrote:
On 11/12/2018 9:30 pm, Dmitry Chuyko wrote:
On 12/11/18 4:03 AM, David Holmes wrote:
Hi Dmitry,
On 11/12/2018 12:16 am, Dmitry Chuyko wrote:
Hello,
Please review a small fix in java_md_solinux.c: continuation is not
truly compatible with
On 12/11/18 4:03 AM, David Holmes wrote:
Hi Dmitry,
On 11/12/2018 12:16 am, Dmitry Chuyko wrote:
Hello,
Please review a small fix in java_md_solinux.c: continuation is not
truly compatible with pthread_create start_routine's signature but we
control what actually happens. So it makes
Hello,
Please review a small fix in java_md_solinux.c: continuation is not
truly compatible with pthread_create start_routine's signature but we
control what actually happens. So it makes sense to add intermediate
void* cast to silence the error.
bug: https://bugs.openjdk.java.net/browse/JDK
Hello,
AArch64 aes test runs pass in -Dmode=GCM.
-Dmitry
On 12/2/18 3:37 AM, Vladimir Kozlov wrote:
I am fine with Hotspot changes.
But we need to verify changes on all platforms.
I see that aarch64 also supports it in addition to SPARC.
I will run compiler/codegen/aes/ test to make sure it
same
Interpreter
before 40844 ± 333 ns/op
after 24777 ± 624 ns/op 1.7x
-Dmitry
On 11/16/2017 07:42 PM, Dmitry Chuyko wrote:
On 11/15/2017 09:44 PM, Andrew Haley wrote:
On 15/11/17 18:38, Vitaly Davidovich wrote:
On Wed, Nov 15, 2017 at 12:40 PM, Andrew Haley wrote:
On 15/11/17 15:38
On 11/15/2017 09:44 PM, Andrew Haley wrote:
On 15/11/17 18:38, Vitaly Davidovich wrote:
On Wed, Nov 15, 2017 at 12:40 PM, Andrew Haley wrote:
On 15/11/17 15:38, Alan Bateman wrote:
Moving the nativeOrder out of the loop make sense but I'm curious about
the context for improving this implement
On 11/15/2017 06:38 PM, Alan Bateman wrote:
On 15/11/2017 15:27, Dmitry Chuyko wrote:
Hello,
Please review a performance enhancement for java.util.CRC32C pure
Java implementation.
Moving the nativeOrder out of the loop make sense but I'm curious
about the context for improving
Hello,
Please review a performance enhancement for java.util.CRC32C pure Java
implementation.
rfe: https://bugs.openjdk.java.net/browse/JDK-8191328
webrev: http://cr.openjdk.java.net/~dchuyko/8191328/webrev.00/
some results:
https://bugs.openjdk.java.net/browse/JDK-8191328?focusedCommentId=14
37 matches
Mail list logo
