> On May 27, 2020, at 1:46 AM, Alexey Bakhtin wrote:
>
> Hello Max,
>
> Thank you review.
> If I understand correctly tls-server-end-point channel binding data is a hash
> of server certificate. Different SASL protocols could send cbData
> differently, with different prefix format.
Not sur
> But to my earlier question. please: can the new instructions be moved into
> jdk head first, and then merged into the Panama branch, or not?
The new instructions can be classified as:
1. Instructions that can be matched with NEON instructions directly.
MulVB and SqrtVF have been merged into jdk
Hi Alexey,
Looks good.
Thanks,
Alexander
On 5/26/20 12:26 PM, Alexey Semenyuk wrote:
Please review fix [2] for jpackage bug [1].
Get rid of duplicated code parsing version strings. Move the code
parsing version strings to dedicated classes with unit test coverage.
Also remove Mac specific i
Looks good.
Thanks,
Alexander
On 5/26/20 1:43 PM, Andy Herrick wrote:
revised at [3] to combine JavaOptionsTest and JavaOptionsModular tests
[3] - http://cr.openjdk.java.net/~herrick/8245202/webrev.02/
/Andy
On 5/26/2020 8:08 AM, Andy Herrick wrote:
Please review the fix to issue [1] at [2]
So to try and clarify:
if (Character.toLowerCase(u1) == Character.toLowerCase(u2))
... can never happen today in the context of the StringLatin1 version
of regionMatchesCI (I did a quick check), and a test that exhaustively
tests this property holds should ensure any future unicode updates
doesn
Looks good.
- Alexey
On 5/26/2020 4:43 PM, Andy Herrick wrote:
revised at [3] to combine JavaOptionsTest and JavaOptionsModular tests
[3] - http://cr.openjdk.java.net/~herrick/8245202/webrev.02/
/Andy
On 5/26/2020 8:08 AM, Andy Herrick wrote:
Please review the fix to issue [1] at [2].
The
On 2020-05-26 20:56, fo...@univ-mlv.fr wrote:
- Mail original -
De: "Claes Redestad"
À: "Paul Sandoz"
Cc: "Remi Forax" , "core-libs-dev"
Envoyé: Mardi 26 Mai 2020 20:31:51
Objet: Re: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers
On 2020-05-26 20:02, Paul
Lookup::defineHiddenClass currently throws IAE by ASM if the given bytes
are of unsupported class file version. The implementation should catch
and throw UnsupportedClassVersionError instead.
webrev:
http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/
This patch also includes
David,
Thanks for taking this enhancement, and making it work on the older glibc
(pre 2.17) Linux platforms currently supported by openjdk.
I like that it is a small change to split the JVM startup check on
availability of Posix clock_gettime/getres() APIs and then if additionally
CLOCK_MONOTONIC
Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin:
Hello,
Could you please review the following patch:
JBS: https://bugs.openjdk.java.net/browse/JDK-8245527
Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/
Let's go through your changes statically:
* The JIRA issue title has a typo
Am 2020-05-24 um 01:38 schrieb Michael Osipov:
Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin:
...
What about introducing a UnspecEmptyInetAddress() which gives the proper
AF type, but #getAddress() would return null? This should satisfy the
requirements, InitialToken as well as the RFC. this of c
revised at [3] to combine JavaOptionsTest and JavaOptionsModular tests
[3] - http://cr.openjdk.java.net/~herrick/8245202/webrev.02/
/Andy
On 5/26/2020 8:08 AM, Andy Herrick wrote:
Please review the fix to issue [1] at [2].
The change removes all the old form helper tests and converts the 6
r
I am also concerned about the changes in GSSLibStub.c about the default
value being GSS_C_AF_UNSPECinstead of GSS_C_AF_NULLADDR (line 194-195).
Can you try and see if Window works with GSS_C_AF_NULLADDR? If yes, I'd
prefer to not changing the default value for addresstype for the same
reason w
Hi all,
Here's the implementation of the recently-posted JEP 385, deprecation of RMI
Activation for removal.
I'm listing this as S ("small") since conceptually it's fairly small, though
there are rather a large number of files changed. Essentially the changes are:
- java.rmi.activation pac
Please review fix [2] for jpackage bug [1].
Get rid of duplicated code parsing version strings. Move the code
parsing version strings to dedicated classes with unit test coverage.
Also remove Mac specific identifier setting in app's config file from
the shared code.
- Alexey
[1] https://bug
- Mail original -
> De: "Claes Redestad"
> À: "Paul Sandoz"
> Cc: "Remi Forax" , "core-libs-dev"
>
> Envoyé: Mardi 26 Mai 2020 20:31:51
> Objet: Re: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory
> prependers
> On 2020-05-26 20:02, Paul Sandoz wrote:
>> I prefer the first
On 2020-05-26 20:02, Paul Sandoz wrote:
I prefer the first revision from a simplicity perspective.
Are there any measurable benefits in the subsequent revision? It requires some
careful reading, where the logic in the prepender is duplicated in the layering
of the computeIfAbsent functions.
I prefer the first revision from a simplicity perspective.
Are there any measurable benefits in the subsequent revision? It requires some
careful reading, where the logic in the prepender is duplicated in the layering
of the computeIfAbsent functions. Which, if needed, is fine.
Are the existin
Not completely sure about which of the involved apIs have what possible
extensions. Maybe we can somehow make two mechanisms one which is the
compatible default and one would be the rfc compliant method. Then SASL can be
configured and use different mechanism names with a new propert? That would
Hello Max,
Thank you review.
If I understand correctly tls-server-end-point channel binding data is a hash
of server certificate. Different SASL protocols could send cbData differently,
with different prefix format. This is a reason I create TLSChannelBinding class
and calculate hash from the L
> On May 22, 2020, at 4:27 AM, Alan Bateman wrote:
>
>
>
> On 22/05/2020 04:28, Mikael Vidstedt wrote:
>> Please review this change which cleans up the libjli related files a bit:
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245600
>> webrev:
>> http://cr.openjdk.java.net/~mikael/w
Hello Aleks, Daniel,
Thank you for your comments.
I don’t like that the code is split into several modules too. The reason of
doing it is I can not get TLS server certificate from the JGSS/Kerberos code.
The only place Where I can fetch it is LdapClient.
If I understand your idea correctly, I ca
On Tue, May 26, 2020 at 4:07 AM Christoph Dreis
wrote:
>
> Hi Martin,
>
> > Not a review, but:
> > Compare with the variant of this code in StringUTF16.
> > StringLatin1 only ever needs to support the first 256 chars in Unicode
>
> Does it really? That makes me wonder even more about the addition
On 2020-05-26 00:48, fo...@univ-mlv.fr wrote:
Not sure in which sense you mean inlining? Few of the methods in the
bootstrap code are likely hot enough to see inlining by a JIT - and the
resulting MHs should be identical, just not constructed over and over
again.
I'm wondering if the code withou
Hi David,
This is not a review for the posix code.
Your webrev looks good to me and corresponds to what I expected
to see. I understand that not all operating systems / platforms
are expected to have the nano second precision, so your test
probably can't go much beyond what is currently being te
Hi Alexey,
I agree with all Daniel's comments.
Few thoughts about moving the implementation down to SASL layers:
Will it be possible to make this new code specific only for
JGSS/Kerberos authentication mechanism?
Maybe investigate moving all the new code to GssKrb5Client SASL client
implementa
I have a question on GssKrb5Client.java:
Do you think it's a good idea to let the SASL mechanism understand what TLS
binding is? Instead of passing the whole TlsChannelBinding object through a
SASL property, is it possible to only pass the actual cbData? After all, the
name "com.sun.security.sa
Looks good.
For the diagnostic, longer term it would be nice to generalize those:
# 0: token, 1: token
2168 compiler.err.expected2=\
2169 {0} or {1} expected
2170
2171 # 0: token, 1: token, 2: token
2172 compiler.err.expected3=\
2173 {0}, {1}, or {2} expected
2174
2175 # 0: token, 1: to
Hi Roger,
thank you for reviewing.
I felt adding the micro wouldn't add much, since HashMap is such a
common occurrence in various benchmarks already.
/Claes
On 2020-05-26 16:32, Roger Riggs wrote:
+1,
Looks fine.
Should the benchmark be included?
Thanks, Roger
On 5/25/20 8:12 AM, Jim La
+1,
Looks fine.
Should the benchmark be included?
Thanks, Roger
On 5/25/20 8:12 AM, Jim Laskey wrote:
+1
(Copyright date)
On May 25, 2020, at 7:02 AM, Claes Redestad wrote:
Hi,
sponsoring this patch from Christoph Dreis.
By pushing down the hash calculation we can optimize lookups
in
Looks good.
Thanks to Mark and you for the improvement and testing.
On 5/26/20 12:59 AM, David Holmes wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8242504
webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/
This work was contributed by Mark Kralj-Taylor:
https://mail.openjdk
Hi Alexey,
This is not a review. A few high level comments however:
For that kind of change that introduce a new environment
property you will need to file a CSR, and probably provide
some release notes as well.
Your changes seem to trigger new IllegalStateException and
UnsupportedOperationExce
I'm not an official OpenJDK reviewer, nor would I be confident
reviewing the native code here.
Stephen
On Tue, 26 May 2020 at 14:28, David Holmes wrote:
>
> On 26/05/2020 6:14 pm, Stephen Colebourne wrote:
> > AFAICT a nanosecond clock is fine from a java.time.* API perspective.
>
> Thanks Stephe
Hi Vyom,
Thanks for looking at this.
On 26/05/2020 6:44 pm, Vyom Tiwari wrote:
Hi David,
we can remove the redundant local variable(jlong result) from if block
as follows.
return jlong(ts.tv_sec) * MILLIUNITS + jlong(ts.tv_nsec) /
NANOUNITS_PER_MILLIUNIT;
Sure. I copied the code from os
On 26/05/2020 6:14 pm, Stephen Colebourne wrote:
AFAICT a nanosecond clock is fine from a java.time.* API perspective.
Thanks Stephen. Is this a review or just a nod of approval? :)
Cheers,
David
-
Stephen
On Tue, 26 May 2020 at 06:01, David Holmes wrote:
bug: https://bugs.openjdk.ja
Hi Michael, Thomas,
Unfortunately we can not fix address type issue with the UnspecEmptyInetAddress
subclass.
We can not create subclass of InetAddress without changing public API.
We can try similar approach but create subclass of ChannelBinding class
instead. It is not so elegant like UnspecEm
Please review the fix to issue [1] at [2].
The change removes all the old form helper tests and converts the 6
remaining tests that used the old helpers into 4 new tests using the new
helpers.
[1] - https://bugs.openjdk.java.net/browse/JDK-8245202
[2] - http://cr.openjdk.java.net/~herrick/82
Hi Martin,
> Not a review, but:
> Compare with the variant of this code in StringUTF16.
> StringLatin1 only ever needs to support the first 256 chars in Unicode
Does it really? That makes me wonder even more about the additional lowercase
check.
> which can never change, unlike StringUTF16,
W
Hi David,
we can remove the redundant local variable(jlong result) from if block as
follows.
return jlong(ts.tv_sec) * MILLIUNITS + jlong(ts.tv_nsec) /
NANOUNITS_PER_MILLIUNIT;
Vyom
On Tue, May 26, 2020 at 10:29 AM David Holmes
wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8242504
>
On 25/05/2020 09:26, Yang Zhang wrote:
> In jdk master, what we need to do is that writing m4 file for existing
> vector instructions and placed them to a new file aarch64_neon.ad.
> If no question, I will do it right away.
I'm not entirely sure that such a change is necessary now. In particular,
AFAICT a nanosecond clock is fine from a java.time.* API perspective.
Stephen
On Tue, 26 May 2020 at 06:01, David Holmes wrote:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8242504
> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/
>
> This work was contributed by Mark Kralj-Taylo
On 5/25/20 6:51 PM, Aleksey Shipilev wrote:
> Thanks!
>
> Maurizio, want to ack this too?
Nevermind, I pushed with Thomas' review and triviality rule.
--
Thanks,
-Aleksey
42 matches
Mail list logo
