* Сергей Цыпанов:
> @@ -105,12 +105,8 @@
> private byte[] getBytes(InputStream is)
> throws IOException
> {
> -byte[] buffer = new byte[8192];
> ByteArrayOutputStream baos = new ByteArrayOutputStream(2048);
> -int n;
> -while ((n = is.read(buffer
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8252248/webrev.01/
- moving shared code to net_util_md.h is avoided
- INTERRUPT_SIGNAL is defined as SIGRTMAX - 2 instead of __SIGRTMAX -
2 for Linux in NativeThread.c
- "#include " is moved out from "#ifdef" in
On 28/08/2020 12:25, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8252248/webrev.01/
- moving shared code to net_util_md.h is avoided
- INTERRUPT_SIGNAL is defined as SIGRTMAX - 2 instead of __SIGRTMAX -
2 for Linux in NativeThrea
Hi,
> Isn't this InputStream::readAllBytes?
thanks for pointing this out! Indeed, InputStream::readAllBytes() allows to
save even more memory:
Mode Cnt Score Error Units
read avgt 50 227.054 ± 1.354 us
* Сергей Цыпанов:
> Hi,
>
>> Isn't this InputStream::readAllBytes?
>
> thanks for pointing this out! Indeed, InputStream::readAllBytes() allows to
> save even more memory:
>
> Mode Cnt Score Error Units
> read avg
I've been poking around the zip internals and am now able to locate the
16 bits of interest. The position of these actual bits does appear to
move around from one test run to another. For now, I guess it's
sufficient to look for the pattern of interest in the signed zip file.
New testcase added
Hi Raffaello,
Missed sending this yesterday, the changes are in the updated webrev.
On 8/23/20 10:42 AM, Raffaello Giulietti wrote:
...
Hi Roger,
here are my notes about the Decoder.
(1) The only serious issue I could find is on L.548. It should read
L.548 CharBuffer cb = CharBuffer.wrap(c
Apologies. Meant to reply yesterday. Your edit looks fine to me.
regards,
Sean.
On 27/08/2020 16:41, Fernando Guallini wrote:
Thanks Sean, updated webrev here:
http://cr.openjdk.java.net/~fguallini/8249699/webrev.01/
Regards,
Fernando
- Original Message -
From: sean.cof...@oracle.com
On 28.08.2020 15:55, Alan Bateman wrote:
On 28/08/2020 12:25, Alexander Scherbatiy wrote:
Hello,
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8252248/webrev.01/
- moving shared code to net_util_md.h is avoided
- INTERRUPT_SIGNAL is defined as SIGRTMAX - 2 instead
On 28/08/2020 15:32, Alexander Scherbatiy wrote:
I run the java/nio/channels tests with the fix. There are five
failed tests that fail with and without the fix:
java/nio/channels/DatagramChannel/AdaptorMulticasting.java
java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java
On 28.08.2020 17:40, Alan Bateman wrote:
On 28/08/2020 15:32, Alexander Scherbatiy wrote:
I run the java/nio/channels tests with the fix. There are five
failed tests that fail with and without the fix:
java/nio/channels/DatagramChannel/AdaptorMulticasting.java
java/nio/channels/Datagra
1. Add a comment on how to generate ZIPBYTES in the test. Not the byte[]
declaration but how the original ZIP file is generated.
2. Does this require a CSR? The POSIX permission one had one.
Thanks,
Max
> On Aug 28, 2020, at 10:17 AM, Seán Coffey wrote:
>
> I've been poking around the zip int
+1
Vyom
On Fri, Aug 28, 2020 at 8:24 PM Alexander Scherbatiy <
alexander.scherba...@bell-sw.com> wrote:
> On 28.08.2020 17:40, Alan Bateman wrote:
>
> > On 28/08/2020 15:32, Alexander Scherbatiy wrote:
> >>
> >> I run the java/nio/channels tests with the fix. There are five
> >> failed tests th
On 28/08/2020 16:18, Weijun Wang wrote:
1. Add a comment on how to generate ZIPBYTES in the test. Not the byte[]
declaration but how the original ZIP file is generated.
I'll add a comment block to the test:
/*
* Created using the createByteArray utility method.
* The zipfile it
Hi Roger,
I'm reading this version
http://cr.openjdk.java.net/~rriggs/webrev-hex-formatter-8251989-1/src/java.base/share/classes/java/util/Hex.java
On 2020-08-28 16:22, Roger Riggs wrote:
Hi Raffaello,
Missed sending this yesterday, the changes are in the updated webrev.
On 8/23/20 10:42 A
Everything looks fine to me.
I’ve added myself as the CSR reviewer. In the Solution section, it probably
should me “The existing warning introduced in JDK-8218021 is expanded to
include symlink”. It is not a new warning.
Thanks,
Max
> On Aug 28, 2020, at 12:05 PM, Seán Coffey wrote:
>
>
> O
Looks good to me. Thanks for checking.
Cheers, Thomas
On Fri, Aug 28, 2020 at 1:25 PM Alexander Scherbatiy <
alexander.scherba...@bell-sw.com> wrote:
> Hello,
>
> Could you review the updated fix:
>http://cr.openjdk.java.net/~alexsch/8252248/webrev.01/
>
> - moving shared code to net_util_
Hi Corey,
A few comments on core-libs side...
The naming convention for methods that end in '0' is usually to indicate
they are the bottom-most method or a native method.
So I think you can/should rename the methods to make the most sense
as to their function.
Comparing with the way that the Ba
Hi,
May I please get reviews and a sponsor for this trivial change:
webrev: http://cr.openjdk.java.net/~fguallini/8249694/webrev.00/
Testbug: https://bugs.openjdk.java.net/browse/JDK-8249694
Tests do not need to have ‘@ignore' because with @requires os.maxMemory is
enough to ensure
JarSigner.java #953: The output debug message can be removed from the code.
JavaUtilZipFileAccess.java #44: Change posixPerms to extraAttrs.
ZipFile.java #661: Suggest to keep the comment and update it with the
additional 4 bits for symlink.
The rest of code changes and CSR look good.
Thanks,
Ha
Hello,
When reviewing some of the documentation in jdk.internal.misc.Unsafe, it
appears that there is some dated information regarding the availability of
“pure barrier” methods (i.e. pure StoreStoreFence sans a LoadStore barrier).
When the storeFence() and loadFence() methods were implemented
Looks like the patch attachment was stripped. I’ll include it inline:
—Ian
diff -r 3e9d813ff918 src/java.base/share/classes/jdk/internal/misc/Unsafe.java
--- a/src/java.base/share/classes/jdk/internal/misc/Unsafe.java Thu Aug 27
20:20:39 2020 +0200
+++ b/src/java.base/share/classes/jdk/internal/
On Fri, Aug 28, 2020 at 1:21 PM Ian Graves wrote:
>
> Looks like the patch attachment was stripped. I’ll include it inline:
> —Ian
>
> ...
> @@ -3458,6 +3462,12 @@
> /**
> * Ensures that stores before the fence will not be reordered with
> * stores after the fence.
> + *
> +
23 matches
Mail list logo
