On Fri, 26 Nov 2021 12:46:59 GMT, Сергей Цыпанов wrote:
> Instead of something like
>
> long x;
> long y;
> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>
> we can use `return Long.compare(x, y);`
>
> All replacements are done with IDE.
src/java.desktop/share/classes/javax/swing/plaf/basic/Basic
t;-XX:-UseSSE42Intrinsics")
// .jvmArgsAppend("-XX:UseAVX=0")
.result("results/"+SSECharAnomalyJMH.class.getSimpleName()+"2.json")
.build();
new Runner(opt).run();
}
}
On 26.11.21 14:42, Michael Bien wrote:
added be
added benchmark results for OpenJDK's StringIndexOf benchmark:
https://github.com/openjdk/jdk/pull/6509#issuecomment-979985594
-michael
On 25.11.21 15:05, Michael Bien wrote:
Hello again,
I was trying to run JDK's benchmarks over night (second attempt
actually) but had some diffi
tf16_mixed_char have all
large error bars (all in StringIndexOfChar).
best regards,
michael
On 23.11.21 17:06, Michael Bien wrote:
On 23.11.21 15:57, Roger Riggs wrote:
Hi Michael,
As you might expect performance of strings is very sensitive and has
been tuned extensively over the years m
e the result.
agreed, I tried the most obvious approach first, but there is a chance
that the fast path can be put into the intrinsified
StringLatin1/StringUTF16 code instead.
-michael
Regards, Roger
On 11/22/21 3:52 PM, Michael Bien wrote:
Hello,
I kept forgetting which variants o
Hello,
I kept forgetting which variants of the String methods perform better
with single-char-Strings and which with char (IDEs had the tendency to
suggest the wrong variant since it changed between JDK releases). So i
wrote JMH benchmarks and noticed that the last method with a performance
d
On Sun, 7 Nov 2021 06:53:12 GMT, kabutz wrote:
>>> The net effect of this change might depend on your workload. If you call
>>> stream() on empty collections that have cheap isEmpty(), this change will
>>> likely improve performance and reduce waste. However, this same change
>>> might do the
On Sat, 6 Nov 2021 22:03:26 GMT, Pavel Rappo wrote:
>> This is a draft proposal for how we could improve stream performance for the
>> case where the streams are empty. Empty collections are common-place. If we
>> iterate over them with an Iterator, we would have to create one small
>> Iterato
On Sun, 7 Nov 2021 03:53:29 GMT, Michael Bien wrote:
>> src/java.base/share/classes/java/util/Collection.java line 743:
>>
>>> 741: */
>>> 742: default Stream stream() {
>>> 743: if (isEmpty()) return Stream.empty();
>>
>>
On Wed, 10 Nov 2021 09:22:32 GMT, Сергей Цыпанов wrote:
> Looking into File.pathSeparator I've found out that currently we initialize
> them as
>
> public static final String separator = "" + separatorChar;
>
> Which after compilation turns into
>
> NEW java/lang/StringBuilder
> DUP
> INVOKES
On Thu, 4 Nov 2021 20:56:45 GMT, Andrew Leonard wrote:
> This PR enables reproducible Jars, Jmods and openjdk image zip files
> (eg.src.zip).
> It provides support for SOURCE_DATE_EPOCH for Jar, Jmod and underlying
> ZipOutputStream's.
> It fixes the following keys issues relating to reproducib
thank you! I replied on the PR.
-michael
On 16.10.21 01:19, Joseph D. Darcy wrote:
PS See https://github.com/openjdk/jdk/pull/5973
-Joe
On 10/14/2021 1:53 PM, Joseph D. Darcy wrote:
On 10/14/2021 10:23 AM, Michael Bien wrote:
is this the right mailing list for javax.lang.model.* discussions
ime.Version to not use enums :)
best regards,
michael
On 09.10.21 20:58, Michael Bien wrote:
Hello,
could javax.lang.model.SourceVersion receive a feature() method
returning the version as an int, analog to java.lang.Runtime.Version?
if (SourceVersion.latest().feature() >= 18) {}
is s
Hello,
could javax.lang.model.SourceVersion receive a feature() method
returning the version as an int, analog to java.lang.Runtime.Version?
if (SourceVersion.latest().feature() >= 18) {}
is simpler than comparing enums which may or may not exist dependent on
the deployed java version and cl
On Tue, 15 Jun 2021 12:34:50 GMT, Andrey Turbanov
wrote:
>> src/java.base/share/classes/java/security/Security.java line 656:
>>
>>> 654: return null;
>>> 655:
>>> 656: return candidates.toArray(new Provider[0]);
>>
>> `candidates.toArray(new Provider[candidates.size()]);`
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
> Collection.toArra
source and generated instance will in fact
have good quality.)
—Guy Steele
On Jul 13, 2021, at 11:52 AM, Michael Bien wrote:
just wanted to add that the JEP says: "SplittableRandomGenerator extends
RandomGenerator and also provides
methods named split and splits. Splittability allows the user
sults."
which adds to my suspicion that this might be a api bug.
-michael
On 13.07.21 14:45, Michael Bien wrote:
Hello,
i was wondering if SplittableGenerator.split(SplittableGenerator
source) is missing out on a potential usecase when the source itself
is not splittable. The implementa
Hello,
i was wondering if SplittableGenerator.split(SplittableGenerator source)
is missing out on a potential usecase when the source itself is not
splittable. The implementation looks like it only requires basic calls
which could be also provided by the RandomGenerator interface as source.
On Sun, 30 May 2021 17:30:56 GMT, Markus KARG
wrote:
> This PR-*draft* is **work in progress** and an invitation to discuss a
> possible solution for issue
> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
> yet* intended for a final review.
>
> As proposed in JDK
On Mon, 14 Jun 2021 11:34:50 GMT, Andrey Turbanov
wrote:
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
> use `ArrayList` if a thread-safe implementation is not needed.
> I checked only places where `Vector` was used as local variable.
src/java.base/share/classe
e too...
I understand that this topic might be low priority for overall JVM
development but it would have been nice to have a way to enable libjsig
for webstart/applet applications, since LD_PRELOAD is not an option for
this deployment mechanism.
best regards,
and thanks again,
michael bien
On
rocess anyway... so
there must be a launcher involved which interprets this flags before JVM
launch.
to quote my original mail:
It looks like a good self-defence mechanism for me :)
thanks for the support,
best regards,
Michael Bien
-
Paul
>/ A partial answer: one of the Ho
or me :)
best regards,
Michael Bien
---
http://michael-bien.com
24 matches
Mail list logo