Pushed with https://hg.openjdk.java.net/jdk/jdk/rev/b8231f177eaf
Thank you to all involved
It looks like you created webrev based on old state of jdk or its branch.
Your vm_version_aarch64.cpp change did not apply to latest jdk source.
There are also few copyright year updates for files which already have it.
I fixed it and start new round of testing.
Vladimir K
On 8/4/20 7:09 PM,
Webrev: http://cr.openjdk.java.net/~luhenry/8250902/webrev.03
> I think you need to set flag to false (to overwrite setting on command line)
> in vm_version_*.cpp files on all other CPUs until they have implementation:
Fixed.
> Also I forgot to ask to update copyright year in files you
Hi Ludovic,
Tests are mostly clean so far except:
new 3 MD5 tests failed on aarch64 because UseMD5Intrinsics flag is 'true'
incorrectly:
bool UseMD5Intrinsics = true {diagnostic} {command line}
compiler/intrinsics/sha/sanity/TestMD5MultiBlockIntrinsics.java
Good.
I will run Hotspot and JDK testing and let you know results.
Regards,
Vladimir K
On 8/4/20 1:21 PM, Ludovic Henry wrote:
Webrev: http://cr.openjdk.java.net/~luhenry/8250902/webrev.03
Testing: everything passes with hotspot:tier1 and jdk:tier1 in fastdebug on
Linux-x64.
I would leave
Webrev: http://cr.openjdk.java.net/~luhenry/8250902/webrev.03
Testing: everything passes with hotspot:tier1 and jdk:tier1 in fastdebug on
Linux-x64.
> I would leave this investigation to Intel's Java group. They are expert in
> this area!
Ok, we'll reach out to Intel on our end as well to
Hi Ludovic,
On 8/3/20 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 reversed (get_long_*()
should be called for long_state):
if (long_state) {
state =
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
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 {
>
: Monday, August 3, 2020 4:59 PM
To: Ludovic Henry ;
hotspot-compiler-...@openjdk.java.net; Vivek Deshpande
Cc: core-libs-dev
Subject: Re: RFR[M]: Adding MD5 Intrinsic on x86-64
Hmm, with that code reversed I now have failure only on Windows:
V [jvm.dll+0x43abb7] report_vm_error+0x117
Message-
From: Vladimir Kozlov
Sent: Monday, August 03, 2020 4:10 PM
To: Vivek Deshpande
Cc: Ludovic Henry ;
hotspot-compiler-...@openjdk.java.net; core-libs-dev
; Viswanathan, Sandhya
Subject: Re: RFR[M]: Adding MD5 Intrinsic on x86-64
Thank you, Vivek, for pointer. This is interesting
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]
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
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
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);
}
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
>
> 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
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
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,
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:
>
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
22 matches
Mail list logo
