8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions #61

jatin-bhateja · 2020-09-07T14:28:18Z

Summary:

New AVX3 optimized stubs for both conjoint and disjoint arraycopy.
Special instruction sequence blocks for copy sizes b/w 32-192 bytes.
Block copy operation above 192 bytes is performed using destination address aligned PRE-MAIN-POST loop. Main loop copies 192 byte in one iteration and tail part fall over special instruction sequence blocks.
Both small copy block and aligned loop use 32 byte vector register to prevent and frequency penalty for copy sizes less than AVX3Threshold.
For block size above AVX3Theshold both special blocks and loop operate using 64 byte register.
In case user sets the maximum vector size to 32 bytes, forward copy (disjoint) operations are done using efficient REP MOVS for copy sizes above 4096 bytes.

JMH Results:
System : CascadeLake Server, Intel(R) Xeon(R) Platinum 8280L CPU @ 2.70GHz
Micros : test/micro/org/openjdk/bench/java/lang/ArrayCopy*.java
Baseline : http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_Baseline.txt
WithOpt : http://cr.openjdk.java.net/~jbhateja/8252847/JMH_results/ArrayCopy_AVX3_Stubs_WithOpts.txt

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions

Reviewers

Nils Eliasson (@neliasso - Reviewer) ⚠️ Review applies to 78c4fe7
Vladimir Kozlov (@vnkozlov - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/61/head:pull/61
$ git checkout pull/61

…raycopy.

bridgekeeper · 2020-09-07T14:29:41Z

👋 Welcome back jbhateja! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2020-09-07T14:30:51Z

@jatin-bhateja The following label will be automatically applied to this pull request: hotspot.

When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label (add|remove) "label" command.

mlbridge · 2020-09-07T14:34:12Z

Webrevs

jatin-bhateja · 2020-09-10T16:05:07Z

/label add hotspot-compiler-dev

openjdk · 2020-09-10T16:06:01Z

@jatin-bhateja
The hotspot-compiler label was successfully added.

neliasso · 2020-09-15T13:02:07Z

src/hotspot/cpu/x86/macroAssembler_x86.cpp

+                                       BasicType type, int offset, bool use64byteVector) {
+  assert(MaxVectorSize >= 32, "vector length < 32");
+  use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0;
+  if (use64byteVector == false) {


Change to "!use64byteVector"

neliasso · 2020-09-15T13:02:19Z

src/hotspot/cpu/x86/macroAssembler_x86.cpp

+void MacroAssembler::copy64_avx(Register dst, Register src, XMMRegister xmm, int offset, bool use64byteVector) {
+  assert(MaxVectorSize == 64 || MaxVectorSize == 32, "vector length mismatch");
+  use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0;
+  if (use64byteVector == false) {


Change to "!use64byteVector"

neliasso · 2020-09-15T13:02:27Z

src/hotspot/cpu/x86/macroAssembler_x86.cpp

+void MacroAssembler::copy64_conjoint_avx(Register dst, Register src, XMMRegister xmm, int offset, bool use64byteVector) {
+  assert(MaxVectorSize == 64 || MaxVectorSize == 32, "vector length mismatch");
+  use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0;
+  if (use64byteVector == false) {


Change to "!use64byteVector"

neliasso · 2020-09-15T13:03:04Z

src/hotspot/cpu/x86/vm_version_x86.cpp


  if (!FLAG_IS_DEFAULT(AVX3Threshold)) {
-    if (!is_power_of_2(AVX3Threshold)) {
+    if (AVX3Threshold !=0 && !is_power_of_2(AVX3Threshold)) {


Missing space before '0'

neliasso · 2020-09-15T13:06:10Z

src/hotspot/cpu/x86/macroAssembler_x86.cpp

+void MacroAssembler::copy64_masked_avx(Register dst, Register src, XMMRegister xmm,
+                                       KRegister mask, Register length, Register temp,
+                                       BasicType type, int offset, bool use64byteVector) {
+  assert(MaxVectorSize >= 32, "vector length < 32");


Why does "MaxVectorSize >= 32" imply that "vector length < 32"?

This assert appears in multiple locations.

neliasso · 2020-09-15T13:12:48Z

src/hotspot/cpu/x86/macroAssembler_x86.cpp

+                                       KRegister mask, Register length, Register temp,
+                                       BasicType type, int offset, bool use64byteVector) {
+  assert(MaxVectorSize >= 32, "vector length < 32");
+  use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0;


When do you expect AVX3Threshold to be 0?

As of now when user explicitly pass -XX:AVX3Threshold=0 , default value of AVX3Threshold is 4096.

I don't like that you put special meaning on AVX3Threshold=0 and then have to add additional checks for it in places where you check its power of 2. And you don't check such setting in new tests.

Actually checking for 0 and power of 2 should be done by flag's constraint. See CodeEntryAlignmentConstraintFunc as example.

There is also this strange relation with MaxVectorSize. Also we should consider power level switch for 64 bytes AVX3 vectors. Does it make sense to use it if array length is small (< 4096 default)?

neliasso

I like that you have extracted the avx512 stub code from the rest - that makes it a lot more readable! Overall the new code feels easy to understand and read.

I found one more minor issue (appears in four places).

My only concern is that it's getting hard to follow under what circumstances avx3 instructions are used:
Could it be the case that different thresholds are needed for when you are using avx3 instructions with 32 or 64 byte vectors? Are we sure all variants are tested?

Also - have you thought about supporting oop-copies? You only have to call the BarrierSetAssembler::arraycopy_prologue/epilogue like in the old versions. It's not a requirement for me to approve this - but an encouragement for a future patch.

neliasso · 2020-09-17T13:03:47Z

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp

  address generate_conjoint_int_oop_copy(bool aligned, bool is_oop, address nooverlap_target,
                                         address *entry, const char *name,
                                         bool dest_uninitialized = false) {
+    if (VM_Version::supports_avx512vlbw() && false == is_oop && MaxVectorSize  >= 32) {


"false == is_oop" => !is_oop

neliasso · 2020-09-17T13:04:06Z

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp

  //
  address generate_disjoint_long_oop_copy(bool aligned, bool is_oop, address *entry,
                                          const char *name, bool dest_uninitialized = false) {
+    if (VM_Version::supports_avx512vlbw() && false == is_oop && MaxVectorSize  >= 32) {


false == is_oop => !is_oop

neliasso · 2020-09-17T13:04:21Z

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp

  address generate_conjoint_long_oop_copy(bool aligned, bool is_oop,
                                          address nooverlap_target, address *entry,
                                          const char *name, bool dest_uninitialized = false) {
+    if (VM_Version::supports_avx512vlbw() && false == is_oop && MaxVectorSize  >= 32) {


false == is_oop => !is_oop

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp

jatin-bhateja · 2020-09-18T08:47:16Z

My only concern is that it's getting hard to follow under what circumstances avx3 instructions are used:
Could it be the case that different thresholds are needed for when you are using avx3 instructions with 32 or 64 byte vectors? Are we sure all variants are tested?

Following 2 runtime flags influence the implementation :-

MaxVectorSize: Determined during VM initialization based on the CPUID of the target.
AVX3Theshold: Set to a default value of 4096 bytes based on prior performance analysis.

Following general rules were followed during implementation:

If target support AVX3 features (BW+VL+F) then copy will use 32 byte vectors (YMMs) for both special cases and aligned copy loop. This is default configuration.
If copy length is above AVX3Threshold, then we can safely use 64 byte vectors (ZMMs) for main copy loop (and tail) since bulk of the cycles will be consumed in it.
Leaf level Macro Assembly routines can dynamically choose b/w YMM or ZMM register based on the AVX3Threshold value.
If user forces MaxVectorSize=32 then above 4096 bytes its seen that REP MOVs shows a better performance for disjoint copies. For conjoint/backward copy vector based copy performs better.

Thus, for 32 byte vector we do not need any threshold since they execute at max frequency level.

tier1, tier2 and tier3 did not show any new issues with the changes.

Also - have you thought about supporting oop-copies? You only have to call the

We may not see significant performance improvement considering prologue and epilogue barriers does considerable processing over object arrays.

jatin-bhateja · 2020-09-18T09:07:20Z

BarrierSetAssembler::arraycopy_prologue/epilogue like in the old versions. It's not a requirement for me to approve this - but an encouragement for a future patch.

Yes that's a good pointer, I can explore extending existing GC barriers for array copy as a separate next step.

neliasso

Thanks for the clarification och update!

Reviewed.

openjdk · 2020-09-18T11:20:24Z

@jatin-bhateja This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions

Reviewed-by: neliasso, kvn

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 415 new commits pushed to the master branch:

52e45a3: 8229186: Improve error messages for TestStringIntrinsics failures
6d2c1a6: 8254292: Update JMH devkit to 1.26
2bbf8a2: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)
aaa0a2a: 8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180
7e80c98: 8254261: fix javadocs in jdk.test.lib.Utils
d4b5dfd: 8253857: Shenandoah: Bugs in ShenandoahEvacOOMHandler related code
e9c1905: 8253740: [PPC64] Minor interpreter cleanup
b1448da: 8253900: SA: wrong size computation when JVM was built without AOT
2bc8bc5: 8254265: s390 and linux 32 bit builds broken
4f9a1ff: 8254073: Tokenizer improvements (revised)
... and 405 more: https://git.openjdk.java.net/jdk/compare/e0c8d4420c8e1a84581927cf77314498b8e5aa52...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

vnkozlov · 2020-09-22T03:34:37Z

@jatin-bhateja Can you put summary of performance improvement into JBS?

…opy for reference types.

jatin-bhateja · 2020-09-22T16:39:15Z

@jatin-bhateja Can you put summary of performance improvement into JBS?

Yes, I have added the summary to JBS

jatin-bhateja · 2020-09-25T13:07:20Z

@jatin-bhateja Can you put summary of performance improvement into JBS?

Hi @vnkozlov , @neliasso
Kindly let me know your feedback, If there are no more comments is it ok to integrate this patch.

neliasso

Looks good to me!

vnkozlov

The main concern which is not clear in these changes is ZMM usage which will lower frequency and case performance regression for small arrays.
That is why AVX3Threshold is set to 4096 bytes by default.
Allowing and checking for 0 AVX3Threshold value contradicts that. Would be nice to have clear comment/explanation about that.

I also propose to use Flag constraint() functionality for checking AVX3Threshold value instead of runtime checks everywhere. Separate RFE, please.

vnkozlov · 2020-09-25T19:45:24Z

src/hotspot/cpu/x86/assembler_x86.cpp

 }

+void Assembler::evmovdqu(XMMRegister dst, KRegister mask, Address src, int vector_len, int type) {
+  assert(VM_Version::supports_avx512vlbw(), "");


I suggest to add assert to these 2 new instruction to check 'type' value to make sure only expected types are passed.

vnkozlov · 2020-09-25T19:47:51Z

src/hotspot/cpu/x86/assembler_x86.cpp

+  assert(VM_Version::supports_avx512vlbw(), "");
+  InstructionMark im(this);
+  bool wide = type == T_SHORT || type == T_LONG || type == T_CHAR;
+  bool bwinstr = type == T_BYTE ||  type == T_SHORT || type == T_CHAR;


'bwinstr' is used only once. You may as well directly set 'prefix' here. (Same in second instruction).

vnkozlov · 2020-09-25T19:58:09Z

src/hotspot/cpu/x86/assembler_x86.cpp

+void Assembler::evmovdqu(XMMRegister dst, KRegister mask, Address src, int vector_len, int type) {
+  assert(VM_Version::supports_avx512vlbw(), "");
+  InstructionMark im(this);
+  bool wide = type == T_SHORT || type == T_LONG || type == T_CHAR;


It looks strange but it is correct (I looked on existing evmovdqu* instructions). May be reorder - T_LONG last.

Do you consider replacing existing evmovdqu* instructions with these two?

vnkozlov · 2020-09-25T20:46:25Z

src/hotspot/cpu/x86/macroAssembler_x86.cpp

+                                       KRegister mask, Register length, Register temp,
+                                       BasicType type, int offset, bool use64byteVector) {
+  assert(MaxVectorSize >= 32, "vector length < 32");
+  use64byteVector |= MaxVectorSize > 32 && AVX3Threshold == 0;


I don't like that you put special meaning on AVX3Threshold=0 and then have to add additional checks for it in places where you check its power of 2. And you don't check such setting in new tests.

Actually checking for 0 and power of 2 should be done by flag's constraint. See CodeEntryAlignmentConstraintFunc as example.

There is also this strange relation with MaxVectorSize. Also we should consider power level switch for 64 bytes AVX3 vectors. Does it make sense to use it if array length is small (< 4096 default)?

vnkozlov · 2020-09-25T20:48:10Z

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp

    __ jcc(Assembler::greater, L_copy_8_bytes); // Copy trailing qwords
  }

+#ifndef PRODUCT


macroAssembler_x86.hpp become big. May be we should start thing about splitting arraycopy stubs into separate file.

But lets do that in a another change. It is good that the AVX3 case is separated out in this change - makes it easy to follow.

vnkozlov · 2020-09-25T20:49:19Z

src/hotspot/cpu/x86/stubRoutines_x86.hpp

 enum platform_dependent_constants {
  code_size1 = 20000 LP64_ONLY(+10000),         // simply increase if too small (assembler will crash if too small)
-  code_size2 = 35300 LP64_ONLY(+11400)          // simply increase if too small (assembler will crash if too small)
+  code_size2 = 35300 LP64_ONLY(+21400)          // simply increase if too small (assembler will crash if too small)


This is big increase in size!

vnkozlov · 2020-09-25T20:50:40Z

src/hotspot/cpu/x86/vm_version_x86.cpp


  if (!FLAG_IS_DEFAULT(AVX3Threshold)) {
-    if (!is_power_of_2(AVX3Threshold)) {
+    if (AVX3Threshold != 0 && !is_power_of_2(AVX3Threshold)) {


Consider flag's constraint() instead of runtime these checks. Separate RFE, please.

vnkozlov · 2020-09-25T20:51:05Z

...org.graalvm.compiler.lir.amd64/src/org/graalvm/compiler/lir/amd64/AMD64ArrayCompareToOp.java

        super(TYPE);

-        assert CodeUtil.isPowerOf2(useAVX3Threshold) : "AVX3Threshold must be power of 2";
+        assert useAVX3Threshold == 0 || CodeUtil.isPowerOf2(useAVX3Threshold) : "AVX3Threshold must be power of 2";


You would need to upstream Graal changes.

vnkozlov · 2020-09-25T20:52:28Z

test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyConjoint.java

+ * @summary Optimize arrayCopy using AVX-512 masked instructions.
+ *
+ * @run main/othervm/timeout=600 -XX:-TieredCompilation  -Xbatch -XX:+IgnoreUnrecognizedVMOptions
+ *      -XX:UseAVX=3 -XX:+UnlockDiagnosticVMOptions -XX:ArrayCopyPartialInlineSize=0 -XX:MaxVectorSize=32 -XX:+UnlockDiagnosticVMOptions


ArrayCopyPartialInlineSize flag is not defiled in these changes.
It seems they need to be included in 8252848 changes.

Hi @vnkozlov, I have updated the pull request to cover your comments. Kindly review.
New RFE JDK-8253721 has been created for AVX3Threshold flag related changes (PR-394).

vnkozlov

Yes, this looks better. Reviewed. Before pushing let me test it. I will let you know results.

vnkozlov · 2020-10-09T17:53:13Z

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp

    __ jcc(Assembler::greater, L_copy_8_bytes); // Copy trailing qwords
  }

+#ifndef PRODUCT


vnkozlov · 2020-10-09T20:30:09Z

hs-tier1-3 testing passed on x86 (all OSs).

jatin-bhateja · 2020-10-10T06:28:46Z

/integrate

openjdk · 2020-10-10T06:29:56Z

@jatin-bhateja Since your change was applied there have been 420 commits pushed to the master branch:

ec41046: 8254348: Build fails when cds is disabled after JDK-8247536
e4469d2: 8247536: Support for pre-generated java.lang.invoke classes in CDS static archive
7ec9c8e: 8233214: Remove runtime code not needed with CMS removed
536b35b: 8254319: Shenandoah: Interpreter native-LRB needs to activate during HAS_FORWARDED
be26972: 8253379: [windows] Several jpackage tests failed with error code 1638
52e45a3: 8229186: Improve error messages for TestStringIntrinsics failures
6d2c1a6: 8254292: Update JMH devkit to 1.26
2bbf8a2: 8245543: Cgroups: Incorrect detection logic on some systems (still reproducible)
aaa0a2a: 8254297: Zero and Minimal VMs are broken with undeclared identifier 'DerivedPointerTable' after JDK-8253180
7e80c98: 8254261: fix javadocs in jdk.test.lib.Utils
... and 410 more: https://git.openjdk.java.net/jdk/compare/e0c8d4420c8e1a84581927cf77314498b8e5aa52...master

Your commit was automatically rebased without conflicts.

Pushed as commit 4b5ac3a.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

transformation. This patch fixes java/util/regex/RegExTest.java in jdk:tier1. We need to delete phi from aliases if we detect that its inputs don't ponit to a unique object. We should delete object pea->is_alias(phi) instead of unqiue. unique may be the new object just merged in. Co-authored-by: Xin Liu <xxinliu@amazon.com>

* Update LICENSE file * The experimental version is aimed to refactor the tool * verificationType mistakenly added to source code is renamed to type * Adapted mvn bindings to at8 * Added tests to represent bad stream handling in jdec and correctone in jdis * Made jdec to write output to proper toolOutput instead of bad logOutput * 7903208: [Jasm] Add support for generics (the Signature attribute) * 7902888: Excess entries in BootstrapMethods with the same bsm, bsmKind, bsmArgs * Replaced hardcoded String[] args, by varargs String... where reasonable Once the "tool" mandatory array memebr was removed from each tool's main method, and considering calls from libraries, and form tests where the argument is very often just one file, or more readable "a1", a2"... without new String[]{} declaration, changed those String[] enforcing headers to more benevolent String... * Intentionally removed ACC_SUPER class modifier was causing hotswap to fail When jasm's disasm, modify, asm cycle output binary was used for class hotswap, remote JDK was not accepting it with java.lang.UnsupportedOperationException: class redefinition failed: attempted to change the class modifiers beacuse of ommited supoer keyword (although it have already no real reason) This patch is returning the kwyword without conditions, when it was included in original bytecode * extended test to verify that super is not used always if super is not in source code, then it is not in disambled code * 7903248: jasm: FieldData.ConstantValue holds undefined reference to CP while writing fields to a class * Added support for stdin in jdis * stdin is now read also by jasm,jcod,jdec more tests needed * Removed jdis specific missleading provide method * Tool output moved where it belongs to commons * Removed duplicated declaration of ArrayList<ToolInput> fileList * Changed requireNonNull message in getDataInputStream * Added one more abstraction layer providing highly reusable byte[] based input * Properly exiting after verson is printed * Stream based inputs are now drained once needed, not during construction * reworked stdin read to be initiated by - As a side effect, files and stdin can be read together remove dduplicated code in tests by getting class in compile time added tests and adapted older to new behavior * added tests if asmtools assmble itself into valid bytecode Added two set of tests jdec->jcoder->load jdis->jasm->load Both in two variants, with -g, and without Both jdec->jcoder->load works fine Both jdis->jasm->load now fails on three files from 278: /org/openjdk/asmtools/jasm/JasmEnvironment$InputFile.class, /org/openjdk/asmtools/jcoder/Jcoder.class, /org/openjdk/asmtools/jasm/Parser.class Fail looks valid. Unluckily, the issue where -g disassembled and back assembled com.google.gson.Gson produce invalid bytecode was not hit The class BruteForceHelper is reusable for any set of classes * Naive fix for enforced dot.suffix * repalce stdout by configurable object This checkout is not buildable, but server as showcase for issue with dual logging for compilers * Replaced dualstream logger by wrapper so it can be later made fully customisable * Enabled shared i18n properties via reused asmtools/i18n.props * All four tools now use neww ToolOutput output As a consequence, all four tools by by default prints to stdout, and honours -d properly * Fixed typo which casued behavior regression found by unittests * Refatoed tests so they can harbour resources in maven way * Moved all logging to stderr. use -dls to return original behavior The -dls switch is oging to be removed once stderr is properl adapted * Implemented library-like input and output This commit is adding byte[]/String input/output clasases for direct library usage. Added tests, advertising how simple is usage of those inputs/outputs There are two hunks, which fixes issues ovberlooked in previous refactorings: - traceln now correctly calls getOutputs - jdec now uses proper logger insted of accidental stderr * Enabled -g for jcoder to be set from external code * Temporary workaround around tests being order-sensitive As -g is now making some disassmebld code not asemble-able back, and order of tests is not deterministic, and Options are static, thus if -g is now set in some test, it is not unset in other tests. Real fix is to move Options out of static context to context of environment as it is done for jcoder. * Added github actions Just for record for "act" for local testing. To run with podman based distros, several steps are ncessary. See nektos/act#303 ; especially * nektos/act#303 (comment) * and nektos/act#303 (comment) * the bind and socket eg: systemctl enable --now --user podman.socket systemctl start --user podman.socket export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock ../act/bin/act --bind --container-daemon-socket $XDG_RUNTIME_DIR/podman/podman.sock To rerun the build on clean env, you have to stop and start the podman socket again Without explicit 'mvn test' the tests are not running. Not sure why * 7902888: Excess entries in BootstrapMethods with the same bsm, bsmKind, bsmArgs * Fixed issue when jasm produced only one file from source with multiple ones Added tests for this issue Added test veryfying that the jcoder is not affected * 7903401: jtreg fails if set of jdk tests process jasm,jdis files with defects * 7903402: jdis: tool writes incorrect StackMapTable if the first same_frame has type 0 (openjdk#51) * 7902888: Excess entries in BootstrapMethods with the same bsm, bsmKind, bsmArgs * 7903401: jtreg fails if set of jdk tests process jasm,jdis files with defects * 7903402: jdis: tool writes incorrect StackMapTable if the first same_frame has type 0 * 7902888: Excess entries in BootstrapMethods with the same bsm, bsmKind, bsmArgs * Refactored new ToolInput/Outputs so they reside in own packages and not in original interfaces (openjdk#53) * Refactored new ToolInput/Outputs so they reside in own packages and not in original interfaces * Removed unused imports * Added licence headers * Added ajvadoc description to three main interfaces. * Removed unnecessary guard condition before changging \ to / for fqn * Replaced "\n" by System.lineSeparator() * Used better names for highlighted abbrevations * 7903405: compiler does not warn about instruction arguments that exceed allowed limits (openjdk#54) * 7902888: Excess entries in BootstrapMethods with the same bsm, bsmKind, bsmArgs * 7903401: jtreg fails if set of jdk tests process jasm,jdis files with defects * 7903402: jdis: tool writes incorrect StackMapTable if the first same_frame has type 0 * 7902888: Excess entries in BootstrapMethods with the same bsm, bsmKind, bsmArgs * 7903405: compiler does not warn about instruction arguments that exceed allowed limits * 7903405: compiler does not warn about instruction arguments that exceed allowed limits * Delete ToolOutput.java * Fixed junit test for CODETOOLS-7903405 (openjdk#56) * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 (openjdk#57) * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * Fix tabs * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 (Part II) (openjdk#58) * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * Fix tabs * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * CODETOOLS-7903506: Asmtools: jdis prints BootstrapMethod attribute if detailed output is off (openjdk#59) * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * Fix tabs * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * 7903506: Asmtools: jdis prints BootstrapMethod attribute if detailed output is off * 7903509: jcoder, jasm: add option to override class file version in source file(s) (openjdk#60) * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * Fix tabs * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * 7903509: jcoder, jasm: add option to override class file version in source file(s) * CODETOOLS-7903531: jdis: Suppress printing comments by adding an option (openjdk#61) * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * Fix tabs * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * 7903458: Umbrella: Preparations for switching to Asmtools 8.0 * 7903531: jdis: Suppress printing comments by adding an option --------- Co-authored-by: Jiri Vanek <jvanek@redhat.com>

8252847: New AVX512 optimized stubs for both conjoint and disjoint ar…

b4f4081

…raycopy.

openjdk bot added the rfr Pull request is ready for review label Sep 7, 2020

openjdk bot added the hotspot hotspot-dev@openjdk.org label Sep 7, 2020

openjdk bot added the hotspot-compiler hotspot-compiler-dev@openjdk.org label Sep 10, 2020

neliasso suggested changes Sep 15, 2020

View reviewed changes

8252847: Review comments resolution

0cd42cc

neliasso suggested changes Sep 17, 2020

View reviewed changes

8252847: Review comments resolution

271b645

neliasso approved these changes Sep 18, 2020

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 18, 2020

jatin-bhateja mentioned this pull request Sep 22, 2020

8252848: Optimize small primitive arrayCopy operations through partial inlining using AVX-512 masked instructions #302

Closed

3 tasks

openjdk bot added core-libs core-libs-dev@openjdk.org and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 22, 2020

8252847: Review comments resolution; code reorganized to cover arrayc…

fadd368

…opy for reference types.

openjdk bot added ready Pull request is ready to be integrated rfr Pull request is ready for review labels Sep 22, 2020

jatin-bhateja changed the title ~~8252847: New AVX512 optimized stubs for both conjoint and disjoint arraycopy~~ 8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions Sep 22, 2020

8252847 : Modifying file permission to resolve jcheck failure.

78c4fe7

jatin-bhateja closed this Sep 22, 2020

jatin-bhateja reopened this Sep 22, 2020

neliasso approved these changes Sep 25, 2020

View reviewed changes

vnkozlov suggested changes Sep 25, 2020

View reviewed changes

8252847 : Review comments resolution

2a60627

vnkozlov approved these changes Oct 9, 2020

View reviewed changes

openjdk bot closed this Oct 10, 2020

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Oct 10, 2020

jatin-bhateja deleted the JDK-8252847 branch December 9, 2020 05:25

LifeIsStrange mentioned this pull request Jan 25, 2022

strong performance regression between graalVM EE 8 and EE 11 oracle/graal#3232

Closed

vnkozlov mentioned this pull request Apr 12, 2024

8330185: Potential uncaught unsafe memory copy exception #18766

Closed

3 tasks

8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions #61

8252847: Optimize primitive arrayCopy stubs using AVX-512 masked instructions #61

Uh oh!

Conversation

jatin-bhateja commented Sep 7, 2020 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Download

Uh oh!

bridgekeeper bot commented Sep 7, 2020

Uh oh!

openjdk bot commented Sep 7, 2020

Uh oh!

mlbridge bot commented Sep 7, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

jatin-bhateja commented Sep 10, 2020

Uh oh!

openjdk bot commented Sep 10, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

neliasso left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jatin-bhateja commented Sep 18, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jatin-bhateja commented Sep 18, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

neliasso left a comment

Choose a reason for hiding this comment

Uh oh!

openjdk bot commented Sep 18, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vnkozlov commented Sep 22, 2020

Uh oh!

jatin-bhateja commented Sep 22, 2020

Uh oh!

jatin-bhateja commented Sep 25, 2020

Uh oh!

neliasso left a comment

Choose a reason for hiding this comment

Uh oh!

vnkozlov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

jatin-bhateja commented Sep 7, 2020 •

edited by openjdk bot

Loading

mlbridge bot commented Sep 7, 2020 •

edited

Loading

jatin-bhateja commented Sep 18, 2020 •

edited

Loading

jatin-bhateja commented Sep 18, 2020 •

edited

Loading

openjdk bot commented Sep 18, 2020 •

edited

Loading