02:17
To: Doerr, Martin
Cc: Michihiro Horie ; hotspot-compiler-
d...@openjdk.java.net; core-libs-dev ;
Kazunori Ogata ; jos...@br.ibm.com
Subject: Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
API for Base64 decoding
On 8/27/20 8:07 AM, Doerr, Martin wrote:
I will use __attribut
Note, this patch set is now on a new thread in the mailing list, due to
the switchover from Mercurial to Git.
Regards,
- Corey
On 9/9/20 4:32 PM, Corey Ashford wrote:
On 9/9/20 2:04 PM, Roger Riggs wrote:
Hi Corey,
Right, the continue was so it would go back and check if the
conversion wa
On 9/9/20 2:04 PM, Roger Riggs wrote:
Hi Corey,
Right, the continue was so it would go back and check if the conversion
was
complete. An alternative would be to repeat the check and return if
there was
no bytes left to process.
Another issue I just discovered is that the way the loop is s
Hi Corey,
Right, the continue was so it would go back and check if the conversion was
complete. An alternative would be to repeat the check and return if
there was
no bytes left to process.
Thanks, Roger
On 9/9/20 3:13 PM, Corey Ashford wrote:
On 9/4/20 8:07 AM, Roger Riggs wrote:
Hi Core
On 9/4/20 8:07 AM, Roger Riggs wrote:
Hi Corey,
The idea I had in mind is refactoring the fast path into the method you
call decodeBlock.
Base64: lines 751-768.
It leaves all the unknown/illegal character handling to the Java code.
And yes, it does not need to handle MIME, except to return on
FR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
> API for Base64 decoding
>
> On 8/27/20 8:07 AM, Doerr, Martin wrote:
> >>> I will use __attribute__ ((align(16))) instead of __vector, and make
> >> them arrays of 16 unsigned char.
> > Maybe __vectors works as
Hi Corey,
The idea I had in mind is refactoring the fast path into the method you
call decodeBlock.
Base64: lines 751-768.
It leaves all the unknown/illegal character handling to the Java code.
And yes, it does not need to handle MIME, except to return on illegal
characters.
The patch is at
On 8/27/20 8:07 AM, Doerr, Martin wrote:
I will use __attribute__ ((align(16))) instead of __vector, and make
them arrays of 16 unsigned char.
Maybe __vectors works as expected, too, now. Whatever we use, I'd appreciate to
double-check the alignment e.g. by using gdb.
I don't remember what we
On 8/29/20 1:19 PM, Corey Ashford wrote:
Hi Roger,
Thanks for your reply and thoughts! Comments interspersed below:
On 8/28/20 10:54 AM, Roger Riggs wrote:
...
Comparing with the way that the Base64 encoder was intrinsified, the
method that is intrinsified should have a method body that does
d the offending character. This
provides another good reason to make that change.
Best regards,
Martin
-----Original Message-
From: Doerr, Martin
Sent: Dienstag, 25. August 2020 15:38
To: Corey Ashford ; Michihiro Horie
Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev ; Kazuno
Hi Roger,
Thanks for your reply and thoughts! Comments interspersed below:
On 8/28/20 10:54 AM, Roger Riggs wrote:
Hi Corey,
A few comments on core-libs side...
The naming convention for methods that end in '0' is usually to indicate
they are the bottom-most method or a native method.
So I t
Hi Corey,
A few comments on core-libs side...
The naming convention for methods that end in '0' is usually to indicate
they are the bottom-most method or a native method.
So I think you can/should rename the methods to make the most sense
as to their function.
Comparing with the way that the Ba
ist as far as we can.
Best regards,
Martin
> -Original Message-
> From: Corey Ashford
> Sent: Donnerstag, 27. August 2020 00:17
> To: Doerr, Martin ; Michihiro Horie
>
> Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev d...@openjdk.java.net>; Kazunor
gust 2020 15:38
To: Corey Ashford ; Michihiro Horie
Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev ; Kazunori Ogata ;
jos...@br.ibm.com
Subject: RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
API for Base64 decoding
Hi Corey,
thanks for proposing this change. I have comments and sugges
Message-
From: Doerr, Martin
Sent: Dienstag, 25. August 2020 15:38
To: Corey Ashford ; Michihiro Horie
Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev ; Kazunori Ogata ;
jos...@br.ibm.com
Subject: RE: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
API for Base64 decoding
.cpp
> shenandoahSupport.cpp
> vmStructs_jvmci.cpp
> shenandoahSupport.cpp
> escape.cpp
> runtime.hpp
> stubRoutines.cpp
> stubRoutines.hpp
> vmStructs.cpp
> Good and trivial.
>
>
> Tests:
> I think we should have JTREG tests to check for regressions in t
he future.
Best regards,
Martin
> -Original Message-
> From: Corey Ashford
> Sent: Mittwoch, 19. August 2020 20:11
> To: Michihiro Horie
> Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev d...@openjdk.java.net>; Kazunori Ogata ;
> jos...@br.ibm.com; Doerr,
Here's a revised webrev which includes a JMH benchmark for the decode
operation.
http://cr.openjdk.java.net/~mhorie/8248188/webrev.03/
The added benchmark tries to be "fair" in that it doesn't prefer a large
buffer size, which would favor the intrinsic. It pseudo-randomly (but
reproducibly)
Hi Roger,
Thank you for your reply. I wasn't aware of this practice, and will get
to work on creating and contributing a test.
Regards,
- Corey
On 8/19/20 11:20 AM, Roger Riggs wrote:
Hi Corey,
For changes obviously performance motivated, it is conventional to run a
JMH perf test to demo
Hi Corey,
For changes obviously performance motivated, it is conventional to run a
JMH perf test to demonstate
the improvement and prove it is worthwhile to add code complexity.
I don't see any existing Base64 JMH tests but they would be in the repo
below or near:
test/micro/org/openjdk/
Michihiro Horie posted up a new iteration of this webrev for me. This
time the webrev includes a complete implementation of the intrinsic for
Power9 and Power10.
You can find it here: http://cr.openjdk.java.net/~mhorie/8248188/webrev.02/
Changes in webrev.02 vs. webrev.01:
* The method hea
21 matches
Mail list logo
