On Wed, 14 Apr 2021 20:03:27 GMT, Claes Redestad wrote:
> There's a StringJoinerBenchmark micro added by JDK-8148937 which could
> perhaps be expanded with the scenarios you've experimented with here?
I modified that micro benchmark and added a method to also measure String.join
static method
gs), while creation of garbage has been further reduced to an almost
> garbage-free operation.
>
> So WDYT?
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
Add String.join benchmark method to StringJoinerBenchmark and adjust so
On Wed, 14 Apr 2021 19:54:26 GMT, Florent Guillaume
wrote:
>> While JDK-8148937 improved StringJoiner class by replacing internal use of
>> getChars that copies out characters from String elements into a char[] array
>> with StringBuilder which is somehow more optimal, the improvement was
>>
On Wed, 14 Apr 2021 18:58:57 GMT, Peter Levart wrote:
> While JDK-8148937 improved StringJoiner class by replacing internal use of
> getChars that copies out characters from String elements into a char[] array
> with StringBuilder which is somehow more optimal, the improvement was
&
While JDK-8148937 improved StringJoiner class by replacing internal use of
getChars that copies out characters from String elements into a char[] array
with StringBuilder which is somehow more optimal, the improvement was marginal
in speed (0% ... 10%) and mainly for smaller strings, while GC
On Sun, 20 Dec 2020 22:41:33 GMT, PROgrm_JARvis
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
On Thu, 31 Dec 2020 10:02:01 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
This pull request has now been integrated.
Changeset:
On Mon, 4 Jan 2021 15:57:33 GMT, Richard Reingruber wrote:
>> The bug title and the PR title need to be the same.
>> Editing either one is fine.
>
> But wouldn't it be legal for a compiler (java to bytecode or bytecode to
> machinecode) to replace references of my_local_copy with references to
>
> 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 additional
commit since the last revision:
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
-
Commit messages:
- 8259021 avoid double racy reads from non-volatile fields of SharedSecrets
Changes:
gner for
JDK 15.
Regards, Peter
On Apr 10, 2020, at 5:22 PM, Peter Levart wrote:
Which brings me to this...
If it is a requirement to use -release option to compile ContentSigner
implementation class in order for them to be usable (with some older release of
jarsigner), then Content
will still be
available to the javac with appropriate -release 14 or older option. So
compilation would still succeed.
Peter
On 4/10/20 11:07 AM, Peter Levart wrote:
What's the use of allowing compiling some classes if those classes
can't be used anywhere? They would be unusable in the new release
What's the use of allowing compiling some classes if those classes can't
be used anywhere? They would be unusable in the new release of
jarsigner. Ok, they could be used in some older jarsigner if the classes
were compiled with appropriate -release option. So the usecase for not
removing the
Hi Ivan,
On 10/1/19 10:26 PM, Ivan Gerasimov wrote:
Hello!
The constructors of SocketPermission and FilePermission expect a
String argument with comma-separated list of actions.
If the list is malformed, then the constructors throw
IllegalArgumentException.
It turns out that the current
an option to turn the cache off
completely.
The former one is good by itself, so I filed an enhancement
request [1] with a link to proposal made by Peter Levart [2].
However, as this is an enhancement, it seems unlikely it's going
to be backported to earlier releases of JDK.
Hi Ivan,
On 11/23/2017 01:16 AM, Ivan Gerasimov wrote:
Hi Peter!
Thank you very much for looking into this!
On 11/22/17 1:45 AM, Peter Levart wrote:
Hi Ivan,
Here's my attempt to increase multithreaded scalability of Cache:
http://cr.openjdk.java.net/~plevart/jdk10-dev
Hi Ivan,
Here's my attempt to increase multithreaded scalability of Cache:
http://cr.openjdk.java.net/~plevart/jdk10-dev/8186628_ssl_session_cache_scalability/webrev.01/
Haven't tested this yet, but I thought that since you already have
relevant performance tests, you might want to try this,
Hi Claes,
A nice find! This is certainly a straightforward and low-risk fix for
breaking the initialization cycle problem with JDK-8062389.
Related to VarHandles, the call trace of the initialization cycle also
includes the following part of code in VarHandle:
AccessMode(final
faster a bit.
Regards, Peter
On 03/23/2016 07:01 PM, Peter Levart wrote:
Hi Xuelei,
On 03/23/2016 04:26 AM, Xuelei Fan wrote:
Hi,
Please review the update for the supporting of BigInteger.TWO:
http://cr.openjdk.java.net/~xuelei/8152237/webrev/
BigInteger.valueOf(2) is a common BigInteger
Hi Xuelei,
On 03/23/2016 04:26 AM, Xuelei Fan wrote:
Hi,
Please review the update for the supporting of BigInteger.TWO:
http://cr.openjdk.java.net/~xuelei/8152237/webrev/
BigInteger.valueOf(2) is a common BigInteger value used in binary and
cryptography operation calculation. The
down the road.
Brad
On 1/4/2015 8:25 AM, Peter Levart wrote:
Hi Brad,
So I created another webrev (just removed the unneeded import and
left-over System.out.println from test):
http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.06/
I'll leave it here to rest
-dev.
Thanks everybody for reviews and happy new year!
Regards, Peter
On 01/02/2015 11:58 PM, Bradford Wetmore wrote:
On 1/1/2015 12:22 PM, Peter Levart wrote:
Hi Brad,
Here's next webrev which tries to cover all your comments:
http://cr.openjdk.java.net/~plevart/jdk9-dev
On 12/29/2014 04:51 PM, Alan Bateman wrote:
On 29/12/2014 09:45, Peter Levart wrote:
Thanks for looking at this, Alan.
You're right about File.getCanonicalFile(). It already checks read
permission for a file. The additional explicit check is superfluous.
I have removed it.
With explicit
/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/
I just assigned 8047769 to you. My username is wetmore, Alan is alanb.
I'll note you both as reviewers in the changeset.
On 12/24/2014 3:37 AM, Peter Levart wrote:
Looks like you have a committer status, will you be pushing this?
I
/
Regards, Peter
On 1 Jan 2015, at 19:21, Peter Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com wrote:
On 12/29/2014 04:51 PM, Alan Bateman wrote:
On 29/12/2014 09:45, Peter Levart wrote:
Thanks for looking at this, Alan.
You're right about File.getCanonicalFile(). It already
On 12/29/2014 10:08 AM, Alan Bateman wrote:
On 24/12/2014 11:37, Peter Levart wrote:
Hi Brad,
Thanks for looking into this. Here's updated webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.02/
This mostly looks good to me too, except the permission
be pushing this?
I can, yes. As soon as we clear-out the remaining questions, right?
On 12/18/2014 5:23 AM, Peter Levart wrote:
Hi,
I propose a patch for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8047769
Here's the webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev
Hi,
I propose a patch for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8047769
Here's the webrev:
http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.01/
The patch uses a package-private FileInputStreamPool class that caches
open
On 12/12/2014 02:20 PM, Sean Mullan wrote:
On 12/12/2014 12:04 AM, Bernd Eckenfels wrote:
Just get it and throw it away, it is easier than iterating the
algorithms of the providers.
Yes, probably. But as you note, the other way is to iterate over the
Providers returned by
Hi,
Some time ago I dived into the sinchronization pitfalls of URL /
URLStreamHandler and came up with a possible solution. Here's the thread
(mostly just my comments) and a patch:
http://mail.openjdk.java.net/pipermail/net-dev/2014-July/008592.html
Regards, Peter
On 11/25/2014 03:03 PM,
On 10/05/2014 10:44 PM, Peter Levart wrote:
The 3rd report shows a result of experimental
AtomicIntegerFieldUpdater implementation which loads new VM-anonymous
class for each new instance which allows VM compiler to specialize
code for a particular field. Such implementation is nearly as fast
which
will be harder to make as performant since it not only has to do a type
check on target reference, but also on the value that is written to
memory location (the type of object reference).
Regards, Peter
On Wed, Oct 8, 2014 at 11:38 AM, Peter Levart peter.lev...@gmail.com
wrote:
On 10
On 10/08/2014 01:19 PM, Doug Lea wrote:
On 10/08/2014 05:38 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerCclass/AtomicIntegerFieldUpdater.java
Paul Sandoz has been working on VarHandles (like MethodHandles)
for similar
On 10/04/2014 05:15 AM, Alan Bateman wrote:
On 03/10/2014 08:13, David M. Lloyd wrote:
:
Why the problem occurs
--
The root of the problem traces back to
SecurityManager.checkMemberAccess(). This method is the one
remaining method in all of SecurityManager which uses
On 07/28/2014 03:34 PM, David M. Lloyd wrote:
On 07/24/2014 04:17 AM, Tom Hawtin wrote:
On 23/07/2014 14:40, David M. Lloyd wrote:
On 07/23/2014 07:07 AM, Tom Hawtin wrote:
On 23/07/2014 05:26, David M. Lloyd wrote:
• Always have static initialization blocks be privileged (this does
Hi Sean, Alex
Here's a sum-up post:
http://mail.openjdk.java.net/pipermail/security-dev/2014-June/010700.html
Regards, Peter
On 07/14/2014 04:44 PM, Sean Mullan wrote:
I don't see a pointer to the webrev/patch -- did you forget to include
it?
--Sean
On 07/11/2014 07:33 PM, Martin
To sum-up: We have a problem with TLR initialization since by default it
uses networking code to compute initial seeder value which can execute
user code in at least two situations:
- when sun.net.spi.nameservice.provider system property is defined to
use custom NameService provider
- when
at
startup and never thereafter.
On Fri, Jun 20, 2014 at 7:59 AM, Alan Bateman alan.bate...@oracle.com
wrote:
On 20/06/2014 15:02, Peter Levart wrote:
And, as Martin pointed out, it seems to be used for tests that exercise
particular responses from NameService API to test the behaviour of JDK
classes
On 06/24/2014 06:01 PM, Martin Buchholz wrote:
On Tue, Jun 24, 2014 at 7:03 AM, Peter Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com wrote:
I would rather use SecureRandom.generateSeed() instance method
instead of SecureRandom.nextBytes(). Why? Because every
== '/') return true;
if (c '0' || c '9') return false;
}
return false;
}
Regards, Peter
Sent from my iPhone
On Nov 5, 2013, at 8:55 AM, Peter Levart peter.lev...@gmail.com
mailto:peter.lev...@gmail.com wrote:
On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote
On 11/04/2013 07:12 PM, robert.fi...@oracle.com wrote:
Changeset: 51b002381b35
Author:rfield
Date: 2013-11-04 10:12 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51b002381b35
7194897: JSR 292: Cannot create more than 16 instances of an anonymous class
8027681: Lambda
Hi Robert,
I think this fix is not complete. When one sets the system property
sun.reflect.noInflation=true, reflection proxy is still attempted to be
generated for anonymous classes (see
ReflectionFactory.newMethodAccessor/newConstructorAccessor).
I would also restructure the
Hi Martin,
If you want to optimize for without-security-manager case, then it would
be better this way:
private static void privilegedInterrupt(Thread t) {
if (System.getSecurityManager() == null) {
t.interrupt();
} else {
PrivilegedActionVoid
Changeset: 7557062d2dd2
Author:plevart
Date: 2013-09-19 16:14 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7557062d2dd2
8011940: java.lang.Class.getAnnotations() always enters synchronized method
Reviewed-by: jfranck, chegar, psandoz, shade
!
Changeset: 2281a7f79738
Author:plevart
Date: 2013-08-20 14:13 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2281a7f79738
8022721: AnnotationTypeDeadlockTest.java throws
java.lang.IllegalStateException: unexpected condition
Reviewed-by: alanb, jfranck
!
On Thursday, May 31, 2012 03:22:35 AM mike.dui...@oracle.com wrote:
Changeset: 2c773daa825d
Author:mduigou
Date: 2012-05-17 10:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d
6924259: Remove offset and count fields from java.lang.String
Summary: Removes
46 matches
Mail list logo
