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
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
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
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
rds,
Martin
> -Original Message-
> From: Corey Ashford
> Sent: Dienstag, 1. September 2020 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: R
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
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
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
Hi Corey,
thanks for
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
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
ent: Donnerstag, 27. August 2020 00:17
> To: Doerr, Martin ; Michihiro Horie
>
> Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev d...@openjdk.java.net>; Kazunori Ogata ;
> jos...@br.ibm.com
> Subject: Re: RFR(M): 8248188: [PATCH] Add HotSpotIntrinsicCandidate and
ord ; 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 suggestions
regarding various files.
rom: 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
Hi Corey
p
> 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 the future.
>
> Best reg
t 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, Martin
>
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
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:
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
21 matches
Mail list logo
