On Wed, 18 May 2022 15:44:10 GMT, Quan Anh Mai wrote:
> This patch backs out the changes made by
> [JDK-8285390](https://bugs.openjdk.java.net/browse/JDK-8285390) and
> [JDK-8284742](https://bugs.openjdk.java.net/browse/JDK-8284742) since there
> are failures due to div nodes floating above th
On Mon, 16 May 2022 07:21:27 GMT, Ningsheng Jian wrote:
> This is the REDO of JDK-8269559 and JDK-8275448. Those two backouts finally
> turned to be some system zlib issue in AArch64 macOS, and is not related to
> the patch itself. See [1][2] for details.
>
> This patch is generally the same a
On Wed, 27 Apr 2022 09:13:34 GMT, Jie Fu wrote:
>> Hi all,
>>
>> According to the Vector API doc, the `LSHR` operator computes
>> `a>>>(n&(ESIZE*8-1))`.
>> However, current implementation is incorrect for negative bytes/shorts.
>>
>> The background is that one of our customers try to vectorize
On Fri, 8 Apr 2022 22:17:23 GMT, Srinivas Vamsi Parasa
wrote:
>> Optimizes the divideUnsigned() and remainderUnsigned() methods in
>> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This
>> change shows 3x improvement for Integer methods and upto 25% improvement for
>> Long
On Fri, 1 Apr 2022 15:38:36 GMT, Andrew Haley wrote:
>> Will this patch change `java.lang.Math`, `java.lang.StrictMath` or both?
>> I've noticed differences in iterative machine learning algorithms using exp
>> & log across different JVMs and architectures which we try to track in
>> [Tribuo](
On Tue, 25 May 2021 15:32:40 GMT, gregcawthorne wrote:
>> Glibc 2.29 onwards provides optimised versions of log,log10,exp.
>> These functions have an accuracy of 0.9ulp or better in glibc
>> 2.29.
>>
>> Therefore this patch adds code to parse, store and check
>> the runtime glibcs version in os_
On Fri, 18 Mar 2022 20:19:08 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing fra
On Fri, 18 Mar 2022 20:19:08 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing fra
On Sun, 13 Mar 2022 06:36:15 GMT, Jatin Bhateja wrote:
>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar
>> IR nodes for above intrinsics.
>> - Test creation using new IR testing fra
On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote:
> We observed several failures on macosx aarch64 after integration of
> [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could
> reliably reproduce
> [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8
On Mon, 14 Feb 2022 10:30:09 GMT, Tobias Hartmann wrote:
> We observed several failures on macosx aarch64 after integration of
> [JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could
> reliably reproduce
> [JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8
We observed several failures on macosx aarch64 after integration of
[JDK-8275448](https://bugs.openjdk.java.net/browse/JDK-8275448). I could
reliably reproduce
[JDK-8281512](https://bugs.openjdk.java.net/browse/JDK-8281512) with JDK 18
b25-1665 (the first build with
[JDK-8275448](https://bugs.
On Thu, 28 Oct 2021 08:58:48 GMT, Aleksey Shipilev wrote:
>> `Unsafe.storeStoreFence` currently delegates to stronger
>> `Unsafe.storeFence`. We can teach compilers to map this directly to already
>> existing rules that handle `MemBarStoreStore`. Like explicit
>> `LoadFence`/`StoreFence`, we i
On Wed, 29 Sep 2021 12:36:23 GMT, Claes Redestad wrote:
>> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to
>> work also for ASCII encoding, which makes for example the `UTF_8$Encoder`
>> perform on par with (or outperform) similarly getting charset encoded bytes
>> f
On Tue, 28 Sep 2021 11:49:29 GMT, Claes Redestad wrote:
>> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to
>> work also for ASCII encoding, which makes for example the `UTF_8$Encoder`
>> perform on par with (or outperform) similarly getting charset encoded bytes
>> f
On Mon, 27 Sep 2021 11:59:54 GMT, Claes Redestad wrote:
> > Should we remove the "iso" part from the method/class names?
>
> I'm open to suggestions, but I've not been able to think of anything better.
> `encodeISOOrASCII` doesn't seem helpful and since ASCII is a subset of the
> ISO-8859-1 en
On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote:
> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to
> work also for ASCII encoding, which makes for example the `UTF_8$Encoder`
> perform on par with (or outperform) similarly getting charset encoded bytes
> from
On Wed, 19 May 2021 08:20:13 GMT, Jatin Bhateja wrote:
> Relevant declarations modified and tested with -Werror, no longer see
> unchecked conversion warnings.
>
> Kindly review and approve.
Marked as reviewed by thartmann (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/4
Hi Vladimir,
looks good to me.
Best regards,
Tobias
On 13.01.19 03:46, Vladimir Kozlov wrote:
> http://cr.openjdk.java.net/~kvn/8216151/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8216151
>
> Have to update default.policy after changes in
> jdk.internal.vm.compiler.management files
Hi Claes,
the difference is the "array encoding" (ae) argument passed to the intrinsic.
See
MacroAssembler::string_compare(... int ae). If we compare an UTF16 String, we
know that the number
of bytes is always even (two byte / char encoding), whereas a Latin1 string has
a byte encoding. So
basi
Hi Mandy,
the compiler related changes look good to me.
Please run hs-tier1-3 if you haven't done so yet.
Best regards,
Tobias
On 16.10.18 18:08, Mandy Chung wrote:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8207146/webrev.00/
>
> Unsafe::getObject returns a reference to an
Hi David,
On 27.04.2018 00:04, David Holmes wrote:
>> src/hotspot/share/c1/c1_Canonicalizer.cpp
>> ...
>> void Canonicalizer::do_CheckCast (CheckCast* x) {
>> - if (x->klass()->is_loaded()) {
>> + if (x->klass()->is_loaded() && !x->is_invokespecial_receiver_check())
>>
>> It seems
Hi Sherman,
On 15.12.2017 10:48, Tobias Hartmann wrote:
> I would say it's best to wait for the jdk10 repo to open.
I've checked with Jesper and we can/should quarantine this test right away.
I'll take care of it [1].
Best regards,
Tobias
[1]
http://mail.openjdk.java.net
Hi Sherman,
On 14.12.2017 21:46, Xueming Shen wrote:
> I have a webrev out there. But I will probably have to wait for the
> new jdk10 repo open next week.
>
> Or maybe the hs repo is still open for something like this? and
> you guys can help get it in directly there?
I would say it's best to w
On 30.03.2017 20:24, dean.l...@oracle.com wrote:
> I would like to go with the webrev.2 version, with asserts removed. All the
> reviewers have said they are OK with that version, and it allows more
> complete testing than the minimal version.
Okay, I'm fine with that!
Best regards,
Tobias
>
Hi,
On 22.03.2017 06:09, David Holmes wrote:
> I wonder if the reviewers have fully realized the potential impact here? This
> has exposed a flaw in the way intrinsics are used from core classes.
For the record, I'm fine with both the initial fix as well as the simplified
version. If we don't a
Hi,
On 24.11.2016 00:56, Xueming Shen wrote:
> On 11/23/2016 02:39 PM, Paul Sandoz wrote:
>> Hi,
>>
>> Please review:
>>
>>
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/
>>
>> This patch:
>>
>> 1) updates the StringBuilder/StringBuffer.chars
Hi Rahul,
On 07.11.2016 12:21, Rahul Raghavan wrote:
> Hi,
>
> Request review for closed bug fix - JDK-8159035.
>
> - http://cr.openjdk.java.net/~rraghavan/8159035/webrev.03/
Looks good to me!
> Notes:
>
> 1. - https://bugs.openjdk.java.net/browse/JDK-8159035 -
> (com/sun/crypto/provider/C
Hi,
looks good to me.
Best,
Tobias
On 20.11.2015 19:41, Xueming Shen wrote:
>
> I missed the override version in StringBuffer.java, thanks
> Tobias for catching it.
>
> http://cr.openjdk.java.net/~sherman/8143553
> https://bugs.openjdk.java.net/browse/JDK-8143553
>
> I did re-generate the api
Hi Sherman,
On 19.11.2015 21:27, Xueming Shen wrote:
> Hi
>
> Please help review the change for 8143330.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8143330
> webrev: http://cr.openjdk.java.net/~sherman/8143330/webrev
What about this
733 protected synchronized void getBytes(byte ds
x27;ll ask help from
Sustaining.
Thank you!
Best,
Tobias
Best regards,
Vladimir Ivanov
Best regards,
Vladimir Ivanov
On 6/2/14 10:04 AM, Tobias Hartmann wrote:
On 28.05.2014 12:48, Vladimir Ivanov wrote:
Looks good.
It should be safe to sync on MTF instance since it's not accessi
5/28/14 1:49 PM, Tobias Hartmann wrote:
Hi,
thanks everyone for the feedback!
@Remi: I agree with Paul. This is not a problem because if the normal
read sees an outdated null value, a new LambdaForm is created and
setCachedLambdaForm(...) is executed. This will guarantee that the
non-null val
May 16, 2014, at 4:56 AM, Tobias Hartmann wrote:
Is it sufficient then to use synchronized (lambdaForms) { ... } in
setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
Yes, that is how I see it. The fast path is a racy non-volatile read of a
safely-published structure.
(If
33 matches
Mail list logo
