Please review and sponsor:
https://bugs.openjdk.java.net/browse/JDK-8205461
http://cr.openjdk.java.net/~tvaleev/webrev/8205461/r1/
See also previous discussion thread at [1]. It seems that we did not reach
the final conclusion about the collector name, so in this review it's still
named as "pairi
Hi Vivek,
459 public static int mismatch(float[] a, int aFromIndex,
460float[] b, int bFromIndex,
461int length) {
462 int i = 0;
463 if (length > 1) {
464 if (a[aFromIndex] != b[bFromIndex]) {
4
Hi Vivek!
I think you don't need this if block:
464 if (a[aFromIndex] != b[bFromIndex]) {
465 i = 0;
466 }
i is already 0 anyway, and the following line is just enough.
467 if (a[aFromIndex] == b[bFromIndex]) {
The same applies to other
Hi Paul
I have made the change you have suggested.
Please find the updated webrev at this location:
http://cr.openjdk.java.net/~vdeshpande/vectorizedMismatch_jdk/webrev.02/
Regards,
Vivek
From: Paul Sandoz [mailto:paul.san...@oracle.com]
Sent: Wednesday, June 20, 2018 2:30 PM
To: Deshpande, Vivek
Looks good.
Can you send the updates to the valhalla spec experts please? We told them this
was coming, and minor changes for
clarification.
thanks,
Karen
> On Jun 19, 2018, at 12:41 AM, David Holmes wrote:
>
> Discussions on the CSR request have led to further changes to the
> documentation
+1
Paul.
> On Jun 20, 2018, at 2:18 PM, Stuart Marks wrote:
>
> Hi all,
>
> Please review this small changeset that restores copy semantics to
> List.copyOf() when applied to a sublist of an unmodifiable list.
>
> Webrev:
>
>http://cr.openjdk.java.net/~smarks/reviews/8203184/webrev.0/
>
459 public static int mismatch(float[] a, int aFromIndex,
460float[] b, int bFromIndex,
461int length) {
462 int i = 0;
463 if (length > 1) {
464 if (a[aFromIndex] != b[bFromIndex]) {
465
Hi all,
Please review this small changeset that restores copy semantics to List.copyOf()
when applied to a sublist of an unmodifiable list.
Webrev:
http://cr.openjdk.java.net/~smarks/reviews/8203184/webrev.0/
Bug:
https://bugs.openjdk.java.net/browse/JDK-8203184
Thanks,
s'marks
Hi All
I have updated the webrev with all the suggestions, which passes
ArraysEqCmpTest.java.
Earlier webrev failed the same test.
This webrev also modifies the BufferMismatch.java in similar way.
Please take a look and let me know what you think.
Updated webrev is here:
http://cr.openjdk.java.n
Good; I like the care to distinguish "nested" classes (using the
word "enclosing") from the newer concept of "nests" and "nestmates",
as well as the careful framing of how stuff bubbles up from the classfile.
(Kudos to Alex!)
— John
On Jun 19, 2018, at 9:56 PM, David Holmes wrote:
>
> Some fur
Just a FYI under Linux when you read from urandom the Linux kernel will always
XOR with random bytes generated with x64 rdrand instruction
(arch_get_random_lomg() - if supported). Since it is a XOR it does not have to
trust the quality of this black box hardware implementation.
I would not impl
Hi Nishit,
Looks ok
My only comment would be to put the relative path to the
language-subtag-registry.txt in a private static final constant
to call attention to the dependency on the source layout instead of
burying it in the code.
$.02, Roger
On 6/20/2018 2:27 PM, naoto.s...@oracle.com w
Looks good.
Naoto
On 6/20/18 3:32 AM, Nishit Jain wrote:
Hi,
Please review the fix for JDK-8204938
Bug: https://bugs.openjdk.java.net/browse/JDK-8204938
Webrev: http://cr.openjdk.java.net/~nishjain/8204938/webrev.02/
Fix: Added a test case to cross check the LSR data generated for the JDK
A
Sounds good Sean.
We will push this RFE when your enhancement is ready and reviewed. We
like to avoid pushing this to JDK 11 unless it is being used in "the
current train".
Erik
Thanks for implementing this enhancement Erik. I think it'll prove to
be popular given the functionality availabl
On 2018-06-20 19:09, Alan Bateman wrote:
On 19/06/2018 03:06, Erik Gahlin wrote:
Hi,
Could I have a review of an enhancement that will make it possible to
add JFR events to java.base, and possibly other modules in the JDK,
without a compile time dependency on jdk.jfr.
Bug:
https://bugs.op
> On Jun 19, 2018, at 10:25 PM, mandy chung wrote:
>
> The javadoc update looks good to me.
>
Same here, +1
Paul.
On 20/06/2018 15:52, Dave Hobbs wrote:
Hi Alan,
My understanding is that java.base only exports sun.nio.cs to jdk.charsets
i.e java.base module-info.java has:
...
exports sun.nio.cs to
java.desktop,
jdk.charsets;
...
and jdk.charsets has:
module jdk.charsets {
provides
Thanks for implementing this enhancement Erik. I think it'll prove to be
popular given the functionality available in JFR recordings. I'd agree
with Alan's comment that the Event class could be documented better to
indicate its purpose.
I'm already using this enhancement to implement some new
On 19/06/2018 03:06, Erik Gahlin wrote:
Hi,
Could I have a review of an enhancement that will make it possible to
add JFR events to java.base, and possibly other modules in the JDK,
without a compile time dependency on jdk.jfr.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8203629
Webrev
Hi Erik,
looks good.
Very powerful with minimal intrusion.
Thanks
Markus
-Original Message-
From: Erik Gahlin
Sent: den 19 juni 2018 04:07
To: hotspot-jfr-...@openjdk.java.net; core-libs-dev
Subject: RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr
Hi,
Could
Thank you Alan for review!
I'll push it in a couple of weeks then.
With kind regards,
Ivan
On 6/20/18 5:27 AM, Alan Bateman wrote:
On 11/06/2018 07:15, Ivan Gerasimov wrote:
:
I extended the existing reg. test
java/io/RandomAccessFile/SetLength.java to cover more cases that
involve changi
Hi Pengfei,
On 20 June 2018 at 12:08, Pengfei Li wrote:
> Hi
>
> I have tried the patch (
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html )
> on Ubuntu 18.04 machines (x86_64 & aarch64) with glibc=2.26.1 and build is OK.
>
> There's a small issue within the following
Hi Alan,
My understanding is that java.base only exports sun.nio.cs to jdk.charsets
i.e java.base module-info.java has:
...
exports sun.nio.cs to
java.desktop,
jdk.charsets;
...
and jdk.charsets has:
module jdk.charsets {
provides java.nio.charset.spi.CharsetProvider with
Hey Peter,
I had written a test to test my version of the exit hooks. I can easily
rework it to work with yours. Interested?
To check that the native buffers are reclaimed promptly, we should be able
to amend the test that tests the setting of the max size for the cached
buffers (i.e., check that
On 06/18/2018 05:41 PM, Alan Bateman wrote:
On 17/06/2018 22:20, Peter Levart wrote:
Update: the discussion on concurrent-interest about possible future
addition of public ThreadLocal.getIfPresent() or
ThreadLocal.isPresent() has died out, but it nevertheless reached a
point where ThreadLo
On 20/06/2018 13:39, Baesken, Matthias wrote:
Hi Thomas and Alan, thanks for the reviews.
I adjusted the expression like Thomas suggested and adjusted the file
copyright year too :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205416.1/
Looks okay to me too.
-Alan
On 20/06/2018 14:22, Dave Hobbs wrote:
Hi
We would like to migrate a number of the IBM charsets (which don't need to
be in java.base) to a modular charset provider.
However, as written today our charset classes rely on sun.nio.cs classes
and definitions, which are no longer visible. For example
Hi
We would like to migrate a number of the IBM charsets (which don't need to
be in java.base) to a modular charset provider.
However, as written today our charset classes rely on sun.nio.cs classes
and definitions, which are no longer visible. For example:
sun.nio.cs.HistoricallyNamedCharset
Looks good, Matthias.
..Thomas
On Wed, Jun 20, 2018 at 2:39 PM, Baesken, Matthias
wrote:
> Hi Thomas and Alan, thanks for the reviews.
>
> I adjusted the expression like Thomas suggested and adjusted the file
> copyright year too :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8205416.1/
>
Hi Thomas and Alan, thanks for the reviews.
I adjusted the expression like Thomas suggested and adjusted the file
copyright year too :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205416.1/
Best regards, Matthias
> -Original Message-
> From: Thomas Stüfe [mailto:thomas.stu...@gmai
On Wed, Jun 20, 2018 at 2:30 PM, Alan Bateman wrote:
>
>
> On 20/06/2018 13:16, Thomas Stüfe wrote:
>>
>> :
>>
>> I am curious whether we now get a bunch of follow up errors, since
>> before we never catched a failing CloseHandle. A typical reason why
>> this could fail would be a double close.
>>
On 20/06/2018 13:16, Thomas Stüfe wrote:
:
I am curious whether we now get a bunch of follow up errors, since
before we never catched a failing CloseHandle. A typical reason why
this could fail would be a double close.
Yes, and it typically means that something is seriously broken. We had
e
On 11/06/2018 07:15, Ivan Gerasimov wrote:
:
I extended the existing reg. test
java/io/RandomAccessFile/SetLength.java to cover more cases that
involve changing the file size.
Also I added another regression test, as you Alan suggested, to check
that RandomAccessFile and its FileChannel beha
Good catch.
Could you please change the expression to either
CloseHandle() == FALSE (uppercase)
or
!CloseHandle().
? which would be the standard windows way of writing this.
I am curious whether we now get a bunch of follow up errors, since
before we never catched a failing CloseHandle. A typ
On 20/06/2018 13:09, Baesken, Matthias wrote:
:
Webrev :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205416/
This looks okay me, probably an oversight when this code was refactored.
-Alan
Please review this small fix for a return code handling of windows function
CloseHandle .
MSDN documents CloseHandle here :
https://msdn.microsoft.com/de-de/library/windows/desktop/ms724211(v=vs.85).aspx
Return value
If the function succeeds, the return value is nonzero.
If the
Hi,
Please review the fix for JDK-8204938
Bug: https://bugs.openjdk.java.net/browse/JDK-8204938
Webrev: http://cr.openjdk.java.net/~nishjain/8204938/webrev.02/
Fix: Added a test case to cross check the LSR data generated for the JDK
APIs. So, for each lsr data update, the test case need not be
Hi
I have tried the patch (
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/052991.html ) on
Ubuntu 18.04 machines (x86_64 & aarch64) with glibc=2.26.1 and build is OK.
There's a small issue within the following code in
src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c
U
38 matches
Mail list logo
