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 wa
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 won
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:
r
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: https://git.o
jarsigner 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 Co
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
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 cl
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 i
on 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.
Wi
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/jdk1
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, s
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 Stri
' will be 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 co
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 BigInte
Hi Max,
On 03/30/2015 05:24 PM, Wang Weijun wrote:
I have a customized security manager:
import java.security.AccessController;
import java.security.PrivilegedAction;
public class A3 extends SecurityManager {
public A3() {
// 1. Using lambda
AccessController.doPrivileged
reaks 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 t
it to jdk9-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/~p
47769/webrev.05/
Regards, Peter
On 1 Jan 2015, at 19:21, Peter Levart <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 al
k.java.net/~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 pu
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 exp
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 permi
ou 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/~plevar
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 FileInputStre
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 Security.getProvide
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, Ma
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
eferenceFieldUpdater 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
wrote:
On
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
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 the
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
requir
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 Buchholz
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
- whe
On 06/24/2014 06:01 PM, Martin Buchholz wrote:
On Tue, Jun 24, 2014 at 7:03 AM, Peter Levart <mailto:peter.lev...@gmail.com>> wrote:
I would rather use SecureRandom.generateSeed() instance method
instead of SecureRandom.nextBytes(). Why? Because every
SecureRandom ins
open("/dev/random", O_RDONLY) = 8
[pid 20769] open("/dev/urandom", O_RDONLY) = 9
[pid 20769] open("/dev/urandom", O_RDONLY) = 10
Looking at jdk/src/solaris/classes/sun/security/provider/NativePRNG.java
it looks like 2 file descriptors are created for every variant o
t(i);
if (c == '/') 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 <mailto:peter.lev...@gmail.com>> wrote:
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 Method/Constru
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 seria
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 {
PrivilegedAction doInterrup
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
! src/share/classes/java/lang/Cl
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
! test/java/lang/annot
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: R
47 matches
Mail list logo
