Tighten up argument checking in constructor.
-
Commit messages:
- 8246788: ZoneRules invariants can be broken
Changes: https://git.openjdk.java.net/jdk/pull/2191/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2191&range=00
Issue: https://bugs.openjdk.java.net/browse/
On Fri, 22 Jan 2021 00:48:51 GMT, Johannes Kuhn
wrote:
>> Looks good. What tests have you ran?
>
> On the latest commit, only my own test.
> On the previous commit (4f74e2d) I did run the full tier1.
>
> Currently a full test tier1 run on my machine and github actions is in
> progress.
Tes
this is minor optimization following JDK-8254078.
based on my tests with jmh, it has better performance when apply following
patch:
diff --git a/src/java.base/share/classes/java/io/DataOutputStream.java
b/src/java.base/share/classes/java/io/DataOutputStream.java
index 9a9a687403c..4ea497fc7c0 10
On Fri, 22 Jan 2021 00:44:12 GMT, Mandy Chung wrote:
>> Johannes Kuhn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Implement suggestions by Mandy Chung.
>
> Looks good. What tests have you ran?
On the latest commit, only my own test
On Fri, 22 Jan 2021 00:33:16 GMT, Johannes Kuhn
wrote:
>> Add explicit range check to `MethodHandles.collectArgumentsCheck`.
>> Added test case that exercises all cases.
>>
>> This is a behavioral change, from throwing an unspecified exception to
>> throwing an IllegalArgumentException, as s
> Add explicit range check to `MethodHandles.collectArgumentsCheck`.
> Added test case that exercises all cases.
>
> This is a behavioral change, from throwing an unspecified exception to
> throwing an IllegalArgumentException, as specified.
> No spec change needed, as the IllegalArgumentExce
On Thu, 21 Jan 2021 16:54:36 GMT, Paul Sandoz wrote:
> The intrinsic enables C2 to more reliably elide bounds checks. I don't know
> the exact details but at a high-level it transforms signed values into
> unsigned values (and therefore the signed comparisons become unsigned
> comparisons), wh
On Thu, 21 Jan 2021 22:54:56 GMT, Mandy Chung wrote:
>> Add explicit range check to `MethodHandles.collectArgumentsCheck`.
>> Added test case that exercises all cases.
>>
>> This is a behavioral change, from throwing an unspecified exception to
>> throwing an IllegalArgumentException, as spec
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> got a bit worse after JDK-8258596 which addresses a leak
On Wed, 20 Jan 2021 18:29:00 GMT, Johannes Kuhn
wrote:
> Add explicit range check to `MethodHandles.collectArgumentsCheck`.
> Added test case that exercises all cases.
>
> This is a behavioral change, from throwing an unspecified exception to
> throwing an IllegalArgumentException, as specif
On Thu, 21 Jan 2021 20:48:33 GMT, Claes Redestad wrote:
>> The `StringCoding.resultCached` mechanism is used to remove the allocation
>> of a `StringCoding.Result` object on potentially hot paths used in some
>> `String` constructors. Using a `ThreadLocal` has overheads though, and the
>> over
On Thu, 21 Jan 2021 20:48:33 GMT, Claes Redestad wrote:
>> The `StringCoding.resultCached` mechanism is used to remove the allocation
>> of a `StringCoding.Result` object on potentially hot paths used in some
>> `String` constructors. Using a `ThreadLocal` has overheads though, and the
>> over
On Wed, 20 Jan 2021 23:01:19 GMT, Brian Burkhalter wrote:
> Please review this small change to handle `EINTR` from `close()` in
> `fileDescriptorClose()`. The function `handleGetLength()` is also changed to
> handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the
> file.
Th
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> got a bit worse after JDK-8258596 which addresses a leak
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> got a bit worse after JDK-8258596 which addresses a leak
On Thu, 21 Jan 2021 18:19:10 GMT, Aleksei Efimov wrote:
>> Alexey Bakhtin has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> separate tlsHandshakeCompleted for every StartTLS connection
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Co
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
Add comments and volati
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> got a bit worse after JDK-8258596 which addresses a leak
On Thu, 21 Jan 2021 18:58:53 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8259943: Suppress RESTARTABLE for non-AIX.
>
> src/java.base/unix/native/libjava/io_util_md.c line 173:
>
>> 171:
On Thu, 21 Jan 2021 19:12:16 GMT, Brian Burkhalter wrote:
>> Please review this small change to handle `EINTR` from `close()` in
>> `fileDescriptorClose()`. The function `handleGetLength()` is also changed to
>> handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the
>> file.
> Please review this small change to handle `EINTR` from `close()` in
> `fileDescriptorClose()`. The function `handleGetLength()` is also changed to
> handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the
> file.
Brian Burkhalter has updated the pull request incrementally wi
On Thu, 21 Jan 2021 18:56:59 GMT, Brian Burkhalter wrote:
>> Please review this small change to handle `EINTR` from `close()` in
>> `fileDescriptorClose()`. The function `handleGetLength()` is also changed to
>> handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the
>> file.
> On Jan 21, 2021, at 11:06 AM, Alan Bateman wrote:
>
> On Thu, 21 Jan 2021 18:56:59 GMT, Brian Burkhalter wrote:
>
>>> Please review this small change to handle `EINTR` from `close()` in
>>> `fileDescriptorClose()`. The function `handleGetLength()` is also changed
>>> to handle `EINTR` fr
> Please review this small change to handle `EINTR` from `close()` in
> `fileDescriptorClose()`. The function `handleGetLength()` is also changed to
> handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the
> file.
Brian Burkhalter has updated the pull request incrementally wi
On Thu, 21 Jan 2021 07:32:39 GMT, Alan Bateman wrote:
>> Please review this small change to handle `EINTR` from `close()` in
>> `fileDescriptorClose()`. The function `handleGetLength()` is also changed to
>> handle `EINTR` from `fstat64()` to match other uses of `fstat64()` in the
>> file.
>
>
On Thu, 21 Jan 2021 13:13:38 GMT, Alexey Bakhtin wrote:
>> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
>> Extension.
>> Test from the bug report and jtreg javax/naming tests are passed.
>
> Alexey Bakhtin has updated the pull request incrementally with one additi
On Thu, 21 Jan 2021 09:35:01 GMT, Jie Fu wrote:
>> Unfortunately it is still problematic because you have replaced the
>> intrinsic check (that performed by `Object.checksIndex`, or more
>> specifically
>> [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/intern
On Wed, 20 Jan 2021 15:54:41 GMT, Daniel Fuchs wrote:
>> New ChannelBinding Data will be recreated for every TLS connection and
>> provided to SASL Client in the new environment properties set (cloned from
>> the original).
>> LdapSasl.java lines 133 - 136:
>> TlsChanne
> Please review a small patch to enable LDAP TLS Channel Binding with StartTLS
> Extension.
> Test from the bug report and jtreg javax/naming tests are passed.
Alexey Bakhtin has updated the pull request incrementally with one additional
commit since the last revision:
separate tlsHandshakeCo
> The `StringCoding.resultCached` mechanism is used to remove the allocation of
> a `StringCoding.Result` object on potentially hot paths used in some `String`
> constructors. Using a `ThreadLocal` has overheads though, and the overhead
> got a bit worse after JDK-8258596 which addresses a leak
On Wed, 20 Jan 2021 19:30:41 GMT, Paul Sandoz wrote:
> Unfortunately it is still problematic because you have replaced the intrinsic
> check (that performed by `Object.checksIndex`, or more specifically
> [here](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal
31 matches
Mail list logo