Hi Alexey,
http://cr.openjdk.java.net/~almatvee/8250646/webrev.02/
I removed stop method. Also, if we called abort from MacDMGBundler
exception will be ignored.
Thanks,
Alexander
On 8/3/20 10:10 AM, Alexey Semenyuk wrote:
On 7/31/2020 7:36 PM, alexander.matv...@oracle.com wrote:
Hi Alexe
Thanks Ludovic Detailed explanation and Sandhya for clarification on the
vectorization.
Regards,
Vivek
On Mon, Aug 3, 2020 at 9:07 PM Ludovic Henry wrote:
> Updated webrev: http://cr.openjdk.java.net/~luhenry/8250902/webrev.02
>
> > Next code in inline_digestBase_implCompressMB should be rever
Updated webrev: http://cr.openjdk.java.net/~luhenry/8250902/webrev.02
> Next code in inline_digestBase_implCompressMB should be reversed
> (get_long_*() should be called for long_state):
>
>if (long_state) {
> state = get_state_from_digestBase_object(digestBase_obj);
>} else {
>
I've fixed it at [1]. I'm sending an update very soon as soon as I have the
performance numbers you asked for, and the test suites results on the different
platforms of interest.
[1] http://cr.openjdk.java.net/~luhenry/8250902/webrev.02/
-Original Message-
From: Vladimir Kozlov
Sent:
The link that Vivek shared is for multi-buffer implementation where multiple
MD5 hashes for different buffers is calculated at once using SIMD.
What is needed here is the acceleration of single buffer hash. I think that is
what Henry's patch is proposing.
Best Regards,
Sandhya
-Original M
Hmm, with that code reversed I now have failure only on Windows:
V [jvm.dll+0x43abb7] report_vm_error+0x117 (debug.cpp:264)
V [jvm.dll+0x8a222e] LibraryCallKit::load_field_from_object+0x1ae
(library_call.cpp:5732)
V [jvm.dll+0x88c3ea] LibraryCallKit::get_state_from_digestBase_object+0x3a
Hi David,
On 8/3/2020 4:42 PM, David Holmes wrote:
Hi Joe,
On 4/08/2020 2:24 am, Joe Darcy wrote:
Hi David,
To provide a bit more context, the API was consciously designed to be
future-proofed against the possibility of Java supporting multiple
bounds here (JDK-4891872). As of yet, that cha
Hi Joe,
On 4/08/2020 2:24 am, Joe Darcy wrote:
Hi David,
To provide a bit more context, the API was consciously designed to be
future-proofed against the possibility of Java supporting multiple
bounds here (JDK-4891872). As of yet, that change has not come to pass,
Okay so we want to keep
Thank you, Vivek, for pointer. This is interesting ,could be somehitng Intel's
mlib may have.
Vladimir K
On 8/3/20 3:08 PM, Vivek Deshpande wrote:
Hi Vladimir
It seems that the algorithm can be optimized further using SSE/AVX
instructions. I am not aware of any specific SSE/AVX implementation
Hi Vladimir
It seems that the algorithm can be optimized further using SSE/AVX
instructions. I am not aware of any specific SSE/AVX implementation which
leverages those instructions in the best possible way. Sandhya can chime
in more on that.
As far as I know, I came across this which points to M
I reproduced crash with only MD5 changes on my local linux machine during
fastdebug build.
Next code in inline_digestBase_implCompressMB should be reversed (get_long_*()
should be called for long_state):
if (long_state) {
state = get_state_from_digestBase_object(digestBase_obj);
} e
I've updated [1] with the proper patch.
[1] http://cr.openjdk.java.net/~luhenry/md5-intrinsics/webrev.01/8250902.patch
> And I got crash during JDK build on linux-x64:
>
> # Internal Error (src/hotspot/share/opto/library_call.cpp:5732), pid=18904,
> tid=19012
> # assert(field != __null) failed: undefined field
> #
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug
> 16-internal+0-2020-08-03-1651458.vladimir.kozlo
> But it looks like it has more changes (windows_aarch64) then just MD5
> intrinsic.
> I will retest again with removed other changes.
That looks like a mistake with me learning to use Mercurial, sorry about that.
The only patch you need is `8250902: Implement MD5 Intrinsics on x86`, all the
o
Hmm, I applied your
http://cr.openjdk.java.net/~luhenry/8250902/webrev.01/jdk.changeset
But it looks like it has more changes (windows_aarch64) then just MD5 intrinsic.
I will retest again with removed other changes.
Vladimir K
On 8/3/20 11:12 AM, Ludovic Henry wrote:
And I got crash during J
And I got crash during JDK build on linux-x64:
# Internal Error (src/hotspot/share/opto/library_call.cpp:5732), pid=18904,
tid=19012
# assert(field != __null) failed: undefined field
#
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 16-internal+0-2020-08-03-1651458.vladimir.kozlov.jdkjdk, mixed
I had looked at the java code changes and are fine with them
Tony
> On Aug 3, 2020, at 10:10 AM, Vladimir Kozlov
> wrote:
>
> Hi Ludovic
>
> This is very professional work!
>
> CCing to Core-libs because you modified Java code and need review from Java
> library group.
>
> Few notes:
>
>
On 7/31/2020 7:36 PM, alexander.matv...@oracle.com wrote:
Hi Alexey,
Without modifying some logic in Executor, yes stop is needed. After
retryExecutor.stop(); is executed in MacDmgBundler we will still run
command (same with abort), and this command will fail and exception
will be thrown.
Hi Ludovic
This is very professional work!
CCing to Core-libs because you modified Java code and need review from Java
library group.
Few notes:
Add tests to verify intrinsic implementation. You can use
test/hotspot/jtreg/compiler/intrinsics/sha/ as examples.
In vm_version_x86.cpp move UseM
Hi David,
To provide a bit more context, the API was consciously designed to be
future-proofed against the possibility of Java supporting multiple
bounds here (JDK-4891872). As of yet, that change has not come to pass,
and as you note may never come to pass. So besides in addition to the
link
Hi Tagir,
The implementations are simple, but as you noted there is some subtle behavior
in reporting the key-out-of-range exception.
Changes to the tests look good.
The putIfAbsent and merge implementations result in a change of behavior. For
putIfAbsent, a key out-of-range now results in an
21 matches
Mail list logo
