On Wed, 6 Jan 2021 01:27:52 GMT, Claes Redestad wrote:
>> Hitting up `new MD5()` directly could be a great idea. I expect this would
>> be just as fast as the cache+clone (if not faster), but I'm a bit worried
>> we'd be short-circuiting the ability to install an alternative MD5 provider
>> (w
On Thu, 7 Jan 2021 14:45:03 GMT, Claes Redestad wrote:
>> I've identified a number of optimizations to the plumbing behind
>> `MessageDigest.getDigest(..)` over in #1933 that removes 80-90% of the
>> throughput overhead and all the allocation overhead compared to the
>> `clone()` approach prot
On Tue, 5 Jan 2021 23:08:43 GMT, DellCliff
wrote:
>> Since `java.util.UUID` and `sun.security.provider.MD5` are both in
>> `java.base`, would it make sense to create new instances by calling `new
>> MD5()` instead of `java.security.MessageDigest.getInstance("MD5")` and
>> bypassing the whole
On Wed, 6 Jan 2021 00:41:29 GMT, Claes Redestad wrote:
>> Are you sure you're not ending up paying more using a VarHandle and having
>> to cast and using a var args call `(long) LONG_ARRAY_HANDLE.get(buf, ofs);`
>> instead of creating a ByteBuffer once via
>> `ByteBuffer.wrap(buffer).order(Byt
On Tue, 5 Jan 2021 21:51:51 GMT, DellCliff
wrote:
>> - The MD5 intrinsics added by
>> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
>> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
>> from which the MD5 intrinsic takes inspiration
>>
- The MD5 intrinsics added by
[JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that the
`int[] x` isn't actually needed. This also applies to the SHA intrinsics from
which the MD5 intrinsic takes inspiration
- Using VarHandles we can simplify the code in `ByteArrayAccess` en
On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote:
> - The MD5 intrinsics added by
> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that
> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics
> from which the MD5 intrinsic takes inspiration
>
On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs wrote:
> Followup to the addition of java.util.HexFormat.
> Uses of adhoc hexadecimal conversions are replaced with HexFormat.
> Redundant utility methods are modified or removed.
> In a few places the data being printed is ASN.1 and the test utility
On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs wrote:
> Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format
> hexadecimal strings to use java.util.HexFormat methods.
> Also in tests test/jdk/java/util/Locale/SoftKeys.
This pull request has now been integrated.
Changeset: 876c7fb5
On Fri, 8 Jan 2021 19:35:47 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Limit P11Util::getProvider privileged access to the required
>> 'accessClassInPackage' RuntimePermission only.
>> -
On Thu, 7 Jan 2021 21:23:55 GMT, Sean Mullan wrote:
>> Martin Balao has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Limit P11Util::getProvider privileged access to the required
>> 'accessClassInPackage' RuntimePermission only.
>> - N
On Thu, 7 Jan 2021 19:29:29 GMT, Valerie Peng wrote:
>> As described in JDK-8259319 [1], this fix proposal is to set proper access
>> permissions so the SunPKCS11 provider can create instances of SunJCE classes
>> when a Security Manager is installed and the fallback scheme is used.
>>
>> No r
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback scheme is used.
>
> No regressions found in jdk/sun/security/pkcs11 tests category.
On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs wrote:
> Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format
> hexadecimal strings to use java.util.HexFormat methods.
> Also in tests test/jdk/java/util/Locale/SoftKeys.
+1
-
Marked as reviewed by naoto (Reviewer).
PR:
On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs wrote:
> Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format
> hexadecimal strings to use java.util.HexFormat methods.
> Also in tests test/jdk/java/util/Locale/SoftKeys.
Looks good Roger. Nice cleanup.
-
Marked as revi
Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format hexadecimal
strings to use java.util.HexFormat methods.
Also in tests test/jdk/java/util/Locale/SoftKeys.
-
Commit messages:
- 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code
and locale
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote:
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback scheme is used.
>
> No regres
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote:
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback scheme is used.
>
> No regres
On Fri, 8 Jan 2021 16:50:24 GMT, Attila Szegedi wrote:
>> I checked the code of ClassValue and it can be assumed that it publishes
>> associated values safely. The proof is that it keeps values that it
>> publishes assigned to the final field `java.lang.ClassValue.Entry#value`.
>
> So, are you
> This is an update to javac and javadoc, to introduce support for Preview
> APIs, and generally improve javac and javadoc behavior to more closely adhere
> to JEP 12.
>
> The notable changes are:
>
> * adding support for Preview APIs (javac until now supported primarily only
> preview langua
On Fri, 8 Jan 2021 16:26:09 GMT, Roger Riggs wrote:
>> Followup to the addition of java.util.HexFormat.
>> Uses of adhoc hexadecimal conversions are replaced with HexFormat.
>> Redundant utility methods are modified or removed.
>> In a few places the data being printed is ASN.1 and the test uti
On Fri, 8 Jan 2021 13:32:08 GMT, Peter Levart wrote:
>>> IIUC, your changes mostly all flow from the decision to declare the fields
>>> as non-volatile; if they were still declared as volatile then it'd be
>>> impossible to observe null in them, I think (correct me if I'm wrong; it
>>> seems l
On 1/7/21 12:57 PM, Jason Mehrens wrote:
Hi Doug,
What are your thoughts on promoting monitoring methods from TPE and or FJP to
AbstractExecutorService? The default implementations could just return -1. An
example precedent is OperatingSystemMXBean::getSystemLoadAverage. The
Executors.Dele
> Followup to the addition of java.util.HexFormat.
> Uses of adhoc hexadecimal conversions are replaced with HexFormat.
> Redundant utility methods are modified or removed.
> In a few places the data being printed is ASN.1 and the test utility
> HexPrinter with the ASNFormatter is added.
Roger
On Fri, 8 Jan 2021 15:43:45 GMT, Roger Riggs wrote:
> Followup to the addition of java.util.HexFormat.
> Uses of adhoc hexadecimal conversions are replaced with HexFormat.
> Redundant utility methods are modified or removed.
> In a few places the data being printed is ASN.1 and the test utility
Followup to the addition of java.util.HexFormat.
Uses of adhoc hexadecimal conversions are replaced with HexFormat.
Redundant utility methods are modified or removed.
In a few places the data being printed is ASN.1 and the test utility HexPrinter
with the ASNFormatter is added.
-
C
> This is an update to javac and javadoc, to introduce support for Preview
> APIs, and generally improve javac and javadoc behavior to more closely adhere
> to JEP 12.
>
> The notable changes are:
>
> * adding support for Preview APIs (javac until now supported primarily only
> preview langua
On Fri, 8 Jan 2021 01:51:52 GMT, Jonathan Gibbons wrote:
>> Jan Lahoda has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 57 commits:
>>
>> - Fixing tests after a merge.
>> - Merging master into JDK-8250768
>> - Merging recent mas
On Fri, 8 Jan 2021 13:20:38 GMT, Aleksei Efimov wrote:
>> This issue is blocked by [8258657][1]. It should not be integrated until
>> after 8258657 has been resolved. The JIRA issues have been linked up to
>> reflect this.
>>
>> [1]: https://bugs.openjdk.java.net/browse/JDK-8258657
>
> [JDK-82
On Fri, 8 Jan 2021 13:00:16 GMT, Peter Levart wrote:
>>> So what do you think of this variant:
>>
>> I like it. I originally kept the fields volatile so that we don't observe
>> stale values on `getForward`/`getReverse`, but you're right in that even if
>> we do, the correct value will be obse
On Sat, 19 Dec 2020 10:29:23 GMT, Chris Hegarty wrote:
>> Thank you for checking `HttpURLConnection` and `Socket`.
>> The latest version looks good to me.
>
> This issue is blocked by [8258657][1]. It should not be integrated until
> after 8258657 has been resolved. The JIRA issues have been lin
On 1/8/21 2:03 PM, Peter Levart wrote:
On Fri, 8 Jan 2021 12:23:36 GMT, Attila Szegedi wrote:
IIUC, your changes mostly all flow from the decision to declare the fields as
non-volatile; if they were still declared as volatile then it'd be impossible
to observe null in them, I think (correc
On Fri, 8 Jan 2021 12:47:17 GMT, Attila Szegedi wrote:
>> _(NB: For this leak to occur, an application needs to be either creating and
>> discarding linkers frequently, or creating and discarding class loaders
>> frequently while creating Dynalink type converters for classes in them.
>> Neithe
On Fri, 8 Jan 2021 12:23:36 GMT, Attila Szegedi wrote:
> IIUC, your changes mostly all flow from the decision to declare the fields as
> non-volatile; if they were still declared as volatile then it'd be impossible
> to observe null in them, I think (correct me if I'm wrong; it seems like you
> _(NB: For this leak to occur, an application needs to be either creating and
> discarding linkers frequently, or creating and discarding class loaders
> frequently while creating Dynalink type converters for classes in them.
> Neither is typical usage, although they can occur in dynamic code l
On Fri, 8 Jan 2021 11:06:17 GMT, Peter Levart wrote:
> So what do you think of this variant:
I like it. I originally kept the fields volatile so that we don't observe stale
values on `getForward`/`getReverse`, but you're right in that even if we do,
the correct value will be observed when doin
On Fri, 8 Jan 2021 11:27:57 GMT, Peter Levart wrote:
>> @forax, @plevart could I ask for review once again?
>
> Hi @stsypanov,
>
>> The **behavior** of this convenience method is **identical** to that of
>> c.addAll(Arrays.asList(elements))
>
> What about:
>
>> The **behaviour** of this conv
On Fri, 8 Jan 2021 09:37:23 GMT, Сергей Цыпанов
wrote:
>> Apart from the @SuppressWarnings, this looks good to me.
>> And i like the irony of this.
>
> @forax, @plevart could I ask for review once again?
Hi @stsypanov,
> The **behavior** of this convenience method is **identical** to that of
On Fri, 8 Jan 2021 08:49:44 GMT, Attila Szegedi wrote:
>> Hi Attila,
>>
>> This looks good.
>>
>> If I understand correctly, your `BiClassValue` is a holder for a
>> `BiFunction` and a `BiClassValueRoot` which is a
>> `ClassValue`. The `BiClassValues` contains two lazily
>> constructed Map(s
On Fri, 8 Jan 2021 08:53:19 GMT, Attila Szegedi wrote:
>> _(NB: For this leak to occur, an application needs to be either creating and
>> discarding linkers frequently, or creating and discarding class loaders
>> frequently while creating Dynalink type converters for classes in them.
>> Neithe
Simple fix, complex test case.
Thanks to @AlanBateman for pointing out the right fix.
-
Commit messages:
- * Minor cleanup.
- * Fix Whitespace V2
- * Fix whitespace
- * Fix JDK-8259395 - test now passes
- Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8259395
On Fri, 8 Jan 2021 08:53:19 GMT, Attila Szegedi wrote:
>> _(NB: For this leak to occur, an application needs to be either creating and
>> discarding linkers frequently, or creating and discarding class loaders
>> frequently while creating Dynalink type converters for classes in them.
>> Neithe
On Thu, 17 Dec 2020 10:36:17 GMT, Rémi Forax
wrote:
>> Looks like I've found the original ticket:
>> https://bugs.openjdk.java.net/browse/JDK-8193031
>
> Apart from the @SuppressWarnings, this looks good to me.
> And i like the irony of this.
@forax, @plevart could I ask for review once again?
> _(NB: For this leak to occur, an application needs to be either creating and
> discarding linkers frequently, or creating and discarding class loaders
> frequently while creating Dynalink type converters for classes in them.
> Neither is typical usage, although they can occur in dynamic code l
On Mon, 4 Jan 2021 13:31:41 GMT, Peter Levart wrote:
>> Just a small suggestion using `MethodHandles.empty` instead of
>> `MethodHandles.constant().asType().dropArguments()`.
>
> Hi Attila,
>
> This looks good.
>
> If I understand correctly, your `BiClassValue` is a holder for a `BiFunction`
45 matches
Mail list logo
