+1
Some suggestions (mostly nits):
- in places like src/share/classes/java/util/regex/Pattern.java you
introducesingle-char
strings which might use a char instead:
-result.append("|"+next);
+result.append('|').append(next);
- in places like src/share/classes
On 2018-09-16 07:05, David Black wrote:
On 14 September 2018 at 13:46, David Lloyd wrote:
On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan wrote:
This is a SecurityManager related change which warrants some additional
details for its motivation.
The current System.setSecurityManager() API allo
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ensuring Manifest doesn't
eagerly read in the property value in the static initializer avoids this.
Web
Thanks, Sean!
/Claes
On 2018-10-08 17:47, Sean Mullan wrote:
Looks good to me.
--Sean
On 10/8/18 11:24 AM, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only
On 2018-10-08 17:51, Alan Bateman wrote:
On 08/10/2018 16:24, Claes Redestad wrote:
Hi,
JDK-8207768 cause a noticeable regression in a subset of our startup
tests due eagerly loading security.properties for getting a property
that's only used in exceptional circumstances. Ens
Hi,
please review this patch to use String.isEmpty when applicable:
Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8215281
Why?
- It reads better :-)
- Better startup/warmup due fewer method invocations
- Better peak performance: Strin
On 2018-12-12 17:56, Alan Bateman wrote:
In Checks.java, the parameter change from CharSequence to String means
that "cs" needs to be renamed.
Changed to 'str'
/Claes
On 2018-12-12 17:54, Daniel Fuchs wrote:
Hi Claes,
It might read even better if things like:
+ resultString = !specarg.isEmpty() ? specarg.intern(): opt;
were changed into:
+ resultString = specarg.isEmpty() ? opt : specarg.intern();
best regards,
I only found this pattern
On 2018-12-13 14:06, Daniel Fuchs wrote:
Looks good Claes!
Thanks!
I eyeballed the rest of the patch and found
nothing wrong - but with a patch this size
it would be easy to miss something.
Yes, I've gone through it a couple of times now
to be sure.
Were you able to measure any improveme
Hi Dean,
to avoid escape analysis-eliminated allocations in the past @DontInline
has been sufficient. This means a simpler patch (no changes to native
code needed - added assertions notwithstanding) and passes your tests
with C2 (it'd concern me if Graal's EA sees through this trick, as it
might
ation, and I'm not sure the benefit outweighs the risk.
dl
On 12/15/18 6:48 AM, Claes Redestad wrote:
Hi Dean,
to avoid escape analysis-eliminated allocations in the past @DontInline
has been sufficient. This means a simpler patch (no changes to native
code needed - added assertions notwithsta
Hi,
looks OK as a point fix for now, although we should consider if there
might be more robust ways that avoids hard-coding in flags. E.g, could
+AlwaysPreTouch have unfortunate side-effects on machines with extreme
amounts of RAM if you don't also limit maximum heap size (-Xmx)?
/Claes
On 2019
Hi,
some recent security features have been pushing initialization of
sun.security.util.SecurityProperties to happen earlier in the
bootstrap sequence, which is affecting startup timings on a few
targetted applications.
This patch helps by desugaring potentially early bootstrap lambda use,
and f
On 2019-05-22 12:19, Alan Bateman wrote:
Looks okay although I assume it doesn't matter for the no-SM case.
You mean the SM case? Not as much as the no-SM case, no, which can
be helped a lot in the smallest affected tests.
/Claes
True, I'll skip the desugaring of the else branch, keeps it cleaner.
On 2019-05-22 12:50, Alan Bateman wrote:
On 22/05/2019 11:34, Claes Redestad wrote:
:
You mean the SM case? Not as much as the no-SM case, no, which can
be helped a lot in the smallest affected tests.
Yes, I don't
is no desugaring
so you should probably update the bug description to reflect that.
(I probably would have kept the desugaring in the SM case, but probably
not a big deal either way)
--Sean
On 5/22/19 7:06 AM, Claes Redestad wrote:
True, I'll skip the desugaring of the else branch, keeps it cl
Hi,
by resolving permissions for code source URLs lazily, we can reduce
early class loading during bootstrap, which improves footprint, startup
and reduces the typical bootstrap dependency graph.
Bug:https://bugs.openjdk.java.net/browse/JDK-8229773
Webrev: http://cr.openjdk.java.net/~redesta
Hi,
On 2019-08-15 12:56, Alan Bateman wrote:
On 15/08/2019 11:03, Claes Redestad wrote:
Hi,
by resolving permissions for code source URLs lazily, we can reduce
early class loading during bootstrap, which improves footprint, startup
and reduces the typical bootstrap dependency graph.
Bug
Hi Sean,
On 2019-08-15 15:07, Sean Mullan wrote:
Hi Claes,
I already reviewed an earlier version of this and this is pretty
similar. I did have a question about whether the default serialization
was ok - did you look into that more?
ah, yes.. all the constituents are serializable (whether w
Hi Daniel,
seems prudent, especially if we are to writeReplace the
underlying collection on serialization.
/Claes
On 2019-08-15 17:10, Daniel Fuchs wrote:
Hi Claes,
I wonder if initialize() should check the state of
the readOnly() flag - and if that's true, call
perms.setReadOnly() ?
see Sec
does not change.
Though these are unlikely to be serialized, it will be less likely to
trigger some interoperability issue between different version. It may
need to be documented that serializing/deserializing does not retain the
lazyness.
Roger
On 8/15/19 10:30 AM, Claes Redestad wrote:
Hi
Hi Peter,
by explicitly ensuring the file system has been initialized before
installing a SecurityManager using a hook in System.setSecurityManager,
the patch at hand takes step to ensure things stay neutral w.r.t.
Permission initialization order when using any SecurityManager. It's not
perfectly
On 2019-08-15 21:21, Alan Bateman wrote:
On 15/08/2019 16:22, Claes Redestad wrote:
(adding back core-libs-dev)
Hi Roger,
seems easy enough to add a writeReplace:
http://cr.openjdk.java.net/~redestad/8229773/webrev.02
This mostly looks good. In LazyCodeSourcePermissionCollection it think
Thanks everyone. Pushed.
/Claes
Roger Riggs skrev: (16 augusti 2019 19:00:29 CEST)
>+1
>
>On 8/16/19 12:51 PM, Sean Mullan wrote:
>> +1 from me as well.
>>
>> --Sean
>>
>> On 8/16/19 12:38 PM, Alan Bateman wrote:
>>> On 16/08/2019 13:30
Hi Eric,
benchmarks looks good to me!
Nit: javadoc says "Benchmark measuring DoPrivileged", which doesn't look
right.
/Claes
On 2019-10-03 23:27, [email protected] wrote:
Hi everybody,
Could I get some reviews for JDK-8215521 to add a new JMH for
AccessController.getContext() -- this w
On 2019-10-04 16:25, Eric Caspole wrote:
http://cr.openjdk.java.net/~ecaspole/JDK-8215521/02/webrev/
Looks good to me.
/Claes
+1
/Claes
On 2020-06-08 20:27, [email protected] wrote:
Looks fine to me.
Eric
On 6/8/20 2:15 PM, Anthony Scarpino wrote:
Hi,
I need a quick code review of updates to the microbenchmarks tests for
EC. These tests used curves that are now disabled by default in 15.
https://cr.openj
Hi,
this patch fixes a corner-case performance issue with
Permissions.implies(Permission) by not needing to allocate a mapper
function (or lambda) on each invocation of getPermissionCollection
when there are unresolved permissions present.
Bug: https://bugs.openjdk.java.net/browse/JDK-8247995
llection(p, createEmpty);
- }
- private PermissionCollection createPermissionCollection(Permission p,
- boolean createEmpty) {
synchronized (permsMap) {
Class c = p.getClass();
PermissionCollection pc = permsMap.get(c);
Thanks, Roger
On 6/22/20 11:04 AM, Claes Redestad
2020-06-22 23:54, Claes Redestad wrote:
Hi Roger,
I prototyped it as such, and saw a 0.4ns/op overhead in the
PermissionImplies.withoutPermission. Thinking about it a bit now, this
should be the rare path taken, since it means the permission is not
implied and the performance largely irrelevant. I&#x
On 2020-06-23 00:30, Roger Riggs wrote:
Hi Claes,
Looks good.
Thanks!
Thanks for the followup.
No problem.
/Claes
Roger
On 6/22/20 6:29 PM, Claes Redestad wrote:
Hi,
inlining the new method actually messed up microbenchmark scores a
lot (15-80% overhead). I settled for simplifying
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
> AtomicInteg
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
> AtomicInteg
Thanks for looking at this, Ulf!
On 2016-04-20 17:57, Ulf Zibis wrote:
Hi,
here my comments:
Am 20.04.2016 um 16:44 schrieb Claes Redestad:
Hello,
now that the sun.security.action package is encapsulated we can
simplify internal code to get System properties.
Bug: https
Hello,
now that the sun.security.action package is encapsulated we can simplify
internal code to get System properties.
Bug: https://bugs.openjdk.java.net/browse/JDK-8154231
Webrev: http://cr.openjdk.java.net/~redestad/8154231/webrev.01/
This adds a few convenience methods to GetPropertyActio
as it is. :-)
If this patch is accepted my intention is to file follow-up RFEs for the
other modules.
/Claes
Thanks
Max
On Apr 20, 2016, at 10:44 PM, Claes Redestad wrote:
Hello,
now that the sun.security.action package is encapsulated we can simplify
internal code to get System
On 2016-04-20 20:51, Chris Hegarty wrote:
On 20 Apr 2016, at 15:44, Claes Redestad wrote:
Hello,
now that the sun.security.action package is encapsulated we can simplify
internal code to get System properties.
Bug: https://bugs.openjdk.java.net/browse/JDK-8154231
Webrev: http
Hi,
since JEP-260 encapsulates internal APIs, we could remove unused classes
like this one
hg rm
./src/java.base/share/classes/sun/security/action/GetBooleanSecurityPropertyAction.java
Thanks!
/Claes
Hi,
SSLContextImpl and TrustManagerFactoryImpl has some setup code that
could be
simplified, getting rid of a couple of anonymous classes in the process.
Webrev: http://cr.openjdk.java.net/~redestad/8155039/webrev.00
Bug: https://bugs.openjdk.java.net/browse/JDK-8155039
Alternatively we could
Hi,
JDK-8154231 added methods to simplify access to system properties from
internal code, but after some discussion it's been decided to rename
these methods and document them to make it abundantly clear that they
are performing a privileged action and that care needs to be taken to
tread the
On 2016-05-02 16:15, Sean Mullan wrote:
This looks good.
Thanks!
* src/java.base/share/classes/jdk/Version.java
This is not an issue in your changes, but the current javadoc for
Version.current() says:
266 * @throws SecurityException
267 * If a security manager ex
19:28, Claes Redestad wrote:
Hi,
SSLContextImpl and TrustManagerFactoryImpl has some setup code that
could be
simplified, getting rid of a couple of anonymous classes in the process.
Webrev: http://cr.openjdk.java.net/~redestad/8155039/webrev.00
Bug: https://bugs.openjdk.java.net/browse/JDK-81
no cost:
http://cr.openjdk.java.net/~redestad/8155039/webrev.02/
/Claes
On 2016-05-12 15:37, Claes Redestad wrote:
Hi,
the API this improvement depends on was updated to reflect more clearly
that this
is taking a privileged action:
https://bugs.openjdk.java.net/browse/JDK-8155775
Here'
s
On 2016-06-08 03:24, Xuelei Fan wrote:
Hi Claes,
What's the necessary to get all system properties for just one specific
one? Can you explain more about the necessary to make the change?
Thanks,
Xuelei
On 6/8/2016 3:44 AM, Claes Redestad wrote:
Hi,
there is some lingering concern tha
After some internal discussions:
http://cr.openjdk.java.net/~redestad/8155039/webrev.03/
Drops the PropertiesWrapper and Properties-retrieving approach in favor of a getter
to retrieve multiple properties into a Map.
/Claes
On 2016-06-10 20:13, Mandy Chung wrote:
On Jun 10, 2016, at 4:33 AM
Hi,
changes to SignatureFileVerifier in 9+142 has some startup implications,
and a small
cleanup to avoid some trivial regexes etc reduces number of classes
initialized in affected
startup tests by 61, undoing most of the observed regression.
Webrev: http://cr.openjdk.java.net/~redestad/81689
Hi,
recent changes to FilePermissionCollection to use a lambda in place of
an explicit
BiFunction cause a quite noticeable startup and footprint regression on
small
applications due to a bootstrap dependency. Therefore I'd like to revert
this
particular change.
Bug: https://bugs.openjdk.java
On 2016-12-01 18:10, Alan Bateman wrote:
On 01/12/2016 15:33, Claes Redestad wrote:
Hi,
recent changes to FilePermissionCollection to use a lambda in place
of an explicit
BiFunction cause a quite noticeable startup and footprint regression
on small
applications due to a bootstrap dependency
Hi,
since java.util.concurrent.AtomicReference was changed to use a
VarHandle internally, using it from within the security libraries can
lead to hard to diagnose bootstrap cycles (since VarHandles has to do
doPrivileged calls during setup). The need to initialize VarHandles is
also cause for a s
Hi David,
On 2016-12-30 02:10, David Holmes wrote:
Hi Claes,
On 28/12/2016 12:04 AM, Claes Redestad wrote:
Hi,
since java.util.concurrent.AtomicReference was changed to use a
VarHandle internally, using it from within the security libraries can
lead to hard to diagnose bootstrap cycles
On 12/31/2016 12:45 AM, David Holmes wrote:
I'll let you think about it so more. I'll be back in the office on
Tuesday :)
After giving it some thought I think it's better to just document the need
for some hygiene in the field declaration:
http://cr.openjdk.java.net/~redestad/8172048/webrev.02
On 2017-01-02 18:02, Chris Hegarty wrote:
On 2 Jan 2017, at 11:45, Claes Redestad wrote:
On 12/31/2016 12:45 AM, David Holmes wrote:
I'll let you think about it so more. I'll be back in the office on Tuesday :)
After giving it some thought I think it's better to just do
Hi Adam,
On 01/11/2017 02:34 PM, Adam Petcher wrote:
Please review the following bug fix:
http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/
This fixes a bug in which a permission check would try to load
resources while the system class loader is being initialized.
Resources cannot be l
Hi,
On 01/11/2017 03:56 PM, Adam Petcher wrote:
On 1/11/2017 9:27 AM, Claes Redestad wrote:
Hi Adam,
On 01/11/2017 02:34 PM, Adam Petcher wrote:
Please review the following bug fix:
http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/
This fixes a bug in which a permission check would
Hi again,
On 2017-01-11 15:27, Claes Redestad wrote:
Hi Adam,
On 01/11/2017 02:34 PM, Adam Petcher wrote:
Please review the following bug fix:
http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/
This fixes a bug in which a permission check would try to load
resources while the system
Hi,
please review this fix to various performance regressions observed
as the security model has evolved over the years.
Bug: https://bugs.openjdk.java.net/browse/JDK-8037325
Webrev: http://cr.openjdk.java.net/~redestad/8037325/webrev.01
- For cases where a SecurityManager is not installed, thi
ibs-dev [mailto:[email protected]] On Behalf
Of Claes Redestad
Sent: Thursday, January 12, 2017 3:48 PM
To: core-libs-dev Libs ; Security Dev OpenJDK
Subject: RFR: 8037325: Class.getConstructor() performance regression
Hi,
please review this fix to various performance regressions
On 2017-01-16 22:39, Mandy Chung wrote:
On Jan 12, 2017, at 6:48 AM, Claes Redestad wrote:
Hi,
please review this fix to various performance regressions observed
as the security model has evolved over the years.
Bug: https://bugs.openjdk.java.net/browse/JDK-8037325
Webrev: http
-1
AFAIU, forRemoval=true is not saying anything about *when* each deprecated
method/class will be removed (although there might be an expectation that it
should be in the next major release if possible, i.e., 10); if there's concern
like here that some known application or library won't be re
may count this as an apology and a review. :-)
Thanks!
/Claes
Thanks,
Sean
s'marks
[1] http://openjdk.java.net/jeps/277
On 2/2/17 1:22 PM, Claes Redestad wrote:
-1
AFAIU, forRemoval=true is not saying anything about *when* each
deprecated method/class will be removed (although th
Hi,
please review this simple backout of a startup optimization that has
proven to destabilize things like rmid. Patch inline..
Bug: https://bugs.openjdk.java.net/browse/JDK-8175079
diff -r 87f2a6fb4b9a src/java.base/share/classes/java/lang/System.java
--- a/src/java.base/share/classes/java/l
Done!
On 02/16/2017 05:27 PM, Alan Bateman wrote:
I think go with the first for now.
-Alan
On 16/02/2017 16:24, Claes Redestad wrote:
Hi,
please review this simple backout of a startup optimization that has
proven to destabilize things like rmid. Patch inline..
Bug: https
Hi,
ProtectionDomain creates both the JavaSecurityAccess and the
JavaSecurityProtectionDomainAccess SharedSecrets, and since 9 both are
always created eagerly during early bootstrap. It seems safe to merge
these two, as suggested, which is a tiny startup improvement and cleanup.
Webrev: http
On 2018-04-12 20:45, Sean Mullan wrote:
Please update copyright dates. Otherwise looks fine.
Sure, and thanks for reviewing!
/Claes
Hi,
moving a couple of local permission constants to
sun.security.util.SecurityConstants ensures we delay and avoid loading
permission classes very early during bootstrap. Delaying load is
profitable since it's happening early enough (before System.initPhase1)
to contribute to delaying the in
On 2018-04-30 14:47, Alan Bateman wrote:
This looks okay to me.
Thanks!
Just a few nits - the comment from AccessibleObject has moved to
SecurityConstants. I think it would be better to leave the comment in
AccessibleObject, then you can just comment the SecurityConstants
update with the
On 2018-04-30 15:05, Sean Mullan wrote:
Looks fine to me.
Thanks!
I think the TO DO comment on line 131 of ReflectionFactory can be
removed - it looks like a leftover comment which doesn't seem relevant
anymore.
Sure
/Claes
On 2018-05-24 23:05, Rajan Halade wrote:
Please review this fix to allow exception for equifaxsecureca 90-day
expiry policy. This will allow test to pass but we should work on
removing / replacing this CA later on.
Webrev: http://cr.openjdk.java.net/~rhalade/8203793/webrev.00/
Looks good to
FWIW, but as we're in java.base there's a way to use the
jdk.internal.util.Preconditions API backing Objects.checkFrom* methods
directly, which lets you control the type of exception thrown:
private static final BiFunction,
ArrayIndexOutOfBoundsException> AIOOBE_SUPPLIER
=
Preconditions.o
On Fri, 4 Feb 2022 23:02:21 GMT, Xue-Lei Andrew Fan wrote:
> Please review this trivial code clean up, for a little bit better performance.
There's a small compatibility risk with this change, e.g.,
`List.copyOf(...).contains(null)` will throw NPE while
`Collections.unmodifiableList(...).conta
On Sat, 5 Feb 2022 20:29:50 GMT, Xue-Lei Andrew Fan wrote:
> In [JDK-8281289](https://bugs.openjdk.java.net/browse/JDK-8281289), the
> SSLParameters class was updated with the patch:
>
> - return Collections.unmodifiableList(new
> ArrayList<>(sniNames.values()));
> + return List.copyOf(sniName
On Mon, 7 Mar 2022 15:54:02 GMT, liach wrote:
> Notice list.of will have the downside of copying the input array when the
> size is not small while arrays aslist does not. Is the tradeoff worth it?
A good observation. In a couple of these places we could probably use
`JavaUtilCollectionAccess.
On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeliński wrote:
> During TLS handshake, hundreds of constraints are evaluated to determine
> which cipher suites are usable. Most of the evaluations are performed using
> `HandshakeContext#algorithmConstraints` object. By default that object
> contains
On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeliński wrote:
> During TLS handshake, hundreds of constraints are evaluated to determine
> which cipher suites are usable. Most of the evaluations are performed using
> `HandshakeContext#algorithmConstraints` object. By default that object
> contains
On Tue, 12 Apr 2022 15:19:41 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
>> line 73:
>>
>>> 71:
>>> 72: static AlgorithmConstraints wrap(AlgorithmConstraints
>>> userSpecifiedConstraints) {
>>> 73: if (userSpecifiedConst
On Tue, 12 Apr 2022 11:28:12 GMT, Daniel Jeliński wrote:
> During TLS handshake, hundreds of constraints are evaluated to determine
> which cipher suites are usable. Most of the evaluations are performed using
> `HandshakeContext#algorithmConstraints` object. By default that object
> contains
#8599 would add a new warning. This address the conversions in the
microbenchmark component by means of making the types precise or adding
explicit casts. There's quite a few changes in the ByteBuffers benchmarks, but
the real change is in the template as these are generated.
I've run through a
erated.
>
> I've run through a subset of the affected benchmarks and verified that the
> results are either neutral or improve somewhat (seem to be the case in a few
> of the ByteBuffer micros).
Claes Redestad has updated the pull request incrementally with one addition
On Wed, 11 May 2022 15:21:51 GMT, Aleksey Shipilev wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Copyrights, consistently use the exact accumulator type
>
> test/micro
On Wed, 11 May 2022 15:50:40 GMT, Claes Redestad wrote:
>> #8599 would add a new warning. This address the conversions in the
>> microbenchmark component by means of making the types precise or adding
>> explicit casts. There's quite a few changes in the ByteBuffers
On Wed, 11 May 2022 14:57:16 GMT, Claes Redestad wrote:
> #8599 would add a new warning. This address the conversions in the
> microbenchmark component by means of making the types precise or adding
> explicit casts. There's quite a few changes in the ByteBuffers benchmarks,
On Wed, 11 May 2022 16:39:18 GMT, Aleksey Shipilev wrote:
> > Thanks for reviewing. I'll let the GHA tests complete and integrate this
> > tomorrow if all is clear.
>
> I don't think GHA builds any microbenchmarks (because JMH is not enabled
> there), so there is no point to wait for those.
G
On Tue, 31 May 2022 07:40:56 GMT, Сергей Цыпанов wrote:
>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with
>> smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when
>> called with vararg of size 0, 1, 2.
>>
>> In general replacement of `Arrays.asList(
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote:
> Small change to retrieve the raw bytes of manifest during verifying signed
> JAR.
This seems like a good optimization.
I think comparing the manifest name case insensitively might be preferable -
e.g. using String.equalsIgnoreCase - but
On Mon, 14 Dec 2020 14:46:41 GMT, Maurizio Cimadamore
wrote:
> This patch fixes a problem with type profile pollution when segments of
> different kinds are used on the same memory access var handle, or on the same
> `MemoryAccess` static method.
>
> In principle, argument profiling should ki
On Mon, 14 Dec 2020 18:07:14 GMT, Maurizio Cimadamore
wrote:
>> This patch fixes a problem with type profile pollution when segments of
>> different kinds are used on the same memory access var handle, or on the
>> same `MemoryAccess` static method.
>>
>> In principle, argument profiling shou
On Sun, 20 Dec 2020 19:48:43 GMT, Alan Bateman wrote:
>> I have to say that introducing a ThreadLocal here seems like a step in the
>> wrong direction. With a ThreadLocal, if I read this correctly, a
>> MessageDigest will be cached with each thread that ever calls this API, and
>> it won't be
On Sun, 20 Dec 2020 20:45:55 GMT, Claes Redestad wrote:
>>> I have to say that introducing a ThreadLocal here seems like a step in the
>>> wrong direction. With a ThreadLocal, if I read this correctly, a
>>> MessageDigest will be cached with each thread that ever
On Mon, 28 Dec 2020 21:25:57 GMT, Сергей Цыпанов
wrote:
>>> What about using List.of() instead?
>>
>> For now, the Collections.singletonList() is more compact, which uses one
>> class variable. While List.of(T) shares the internal implementation with
>> List.of(T t1, T t2), which uses two cl
On Mon, 4 Jan 2021 14:27:09 GMT, Peter Levart wrote:
>> See: https://bugs.openjdk.java.net/browse/JDK-8259021
>> See also discussion in thread:
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-December/072798.html
>
> Peter Levart has updated the pull request incrementally with one
By caching default constructors used in
`java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce the
overhead of allocating instances in a variety of places, e.g.,
`MessageDigest::getInstance`, without compromising thread-safety or security.
On the provided microbenchmark `Mes
> SHA-256 avgt 30 265.625 ± 10.465 ns/op
> GetMessageDigest.getInstanceWithProvider:·gc.alloc.rate.norm
> SHA-256 avgt 30 520.030 ± 0.003B/op
>
> See:
> https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#refl
On Mon, 4 Jan 2021 16:40:50 GMT, Claes Redestad wrote:
> By caching default constructors used in
> `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce
> the overhead of allocating instances in a variety of places, e.g.,
> `MessageDigest::getInstan
> SHA-256 avgt 30 265.625 ± 10.465 ns/op
> GetMessageDigest.getInstanceWithProvider:·gc.alloc.rate.norm
> SHA-256 avgt 30 520.030 ± 0.003B/op
>
> See:
> https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.
On Wed, 6 Jan 2021 01:05:35 GMT, Claes Redestad wrote:
>> By caching default constructors used in
>> `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce
>> the overhead of allocating instances in a variety of places, e.g.,
>> `MessageDiges
> SHA-256 avgt 30 265.625 ± 10.465 ns/op
> GetMessageDigest.getInstanceWithProvider:·gc.alloc.rate.norm
> SHA-256 avgt 30 520.030 ± 0.003B/op
>
> See:
> https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#r
On Wed, 6 Jan 2021 20:52:19 GMT, Valerie Peng wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add cloneInstance baseline micro
>
> src/java.base/share/classes/java/security/MessageD
On Thu, 7 Jan 2021 03:59:13 GMT, Claes Redestad wrote:
>> By caching default constructors used in
>> `java.security.Provider::newInstanceUtil` in a `ClassValue`, we can reduce
>> the overhead of allocating instances in a variety of places, e.g.,
>> `MessageDiges
On Thu, 7 Jan 2021 16:39:48 GMT, Peter Levart wrote:
>>> I have to say that introducing a ThreadLocal here seems like a step in the
>>> wrong direction. With a ThreadLocal, if I read this correctly, a
>>> MessageDigest will be cached with each thread that ever calls this API, and
>>> it won't
> SHA-256 avgt 30 265.625 ± 10.465 ns/op
> GetMessageDigest.getInstanceWithProvider:·gc.alloc.rate.norm
> SHA-256 avgt 30 520.030 ± 0.003B/op
>
> See:
> https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.htm
1 - 100 of 152 matches
Mail list logo
