Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8276901: Implement UseHeavyMonitors consistently #6320

Closed
wants to merge 18 commits into from

Conversation

rkennke
Copy link
Contributor

@rkennke rkennke commented Nov 9, 2021

The flag UseHeavyMonitors seems to imply that it makes Hotspot always use inflated monitors, rather than stack locks. However, it is only implemented in the interpreter that way. When it calls into runtime, it would still happily stack-lock. Even worse, C1 uses another flag UseFastLocking to achieve something similar (with the same caveat that runtime would stack-lock anyway). C2 doesn't have any such mechanism at all.
I would like to experiment with disabling stack-locking, and thus, having this flag work as expected would seem very useful.

The change removes the C1 flag UseFastLocking, and replaces its uses with equivalent (i.e. inverted) UseHeavyMonitors instead. I think it makes sense to make UseHeavyMonitors develop (I wouldn't want anybody to use this in production, not currently without this change, and not with this change). I also added a flag VerifyHeavyMonitors to be able to verify that stack-locking is really disabled. We can't currently verify this uncondiftionally (e.g. in debug builds) because all non-x86_64 platforms would need work.

Testing:

  • tier1
  • tier2
  • tier3
  • tier4

Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed
  • Change requires a CSR request to be approved

Issues

  • JDK-8276901: Implement UseHeavyMonitors consistently
  • JDK-8277025: Implement UseHeavyMonitors consistently (CSR)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6320/head:pull/6320
$ git checkout pull/6320

Update a local copy of the PR:
$ git checkout pull/6320
$ git pull https://git.openjdk.java.net/jdk pull/6320/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6320

View PR using the GUI difftool:
$ git pr show -t 6320

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6320.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Nov 9, 2021

👋 Welcome back rkennke! 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
Copy link

@openjdk openjdk bot commented Nov 9, 2021

@rkennke 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 pull request command.

@openjdk openjdk bot added the hotspot label Nov 9, 2021
@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 10, 2021

/cc hotspot-runtime

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 10, 2021

/cc hotspot-compiler

@openjdk openjdk bot added the hotspot-runtime label Nov 10, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 10, 2021

@rkennke
The hotspot-runtime label was successfully added.

@openjdk openjdk bot added the hotspot-compiler label Nov 10, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 10, 2021

@rkennke
The hotspot-compiler label was successfully added.

@rkennke rkennke marked this pull request as ready for review Nov 10, 2021
@openjdk openjdk bot added the rfr label Nov 10, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Nov 10, 2021

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Nov 11, 2021

/label remove hotspot
/csr needed

@rkennke A CSR request is needed here for the change to the UseHeavyMonitors flag, which for historical reasons was a product flag. I wonder if anyone using interpreter-only Zero builds uses this flag?

@openjdk openjdk bot removed the hotspot label Nov 11, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 11, 2021

@dholmes-ora
The hotspot label was successfully removed.

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Nov 11, 2021

How was, and going forward will, this be tested? There are no tests using UseHeavyMonitors. And a real test would be to run a bunch of other tests with the flag applied.

@openjdk openjdk bot added the csr label Nov 11, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Nov 11, 2021

@dholmes-ora has indicated that a compatibility and specification (CSR) request is needed for this pull request.
@rkennke please create a CSR request for issue JDK-8276901. This pull request cannot be integrated until the CSR request is approved.

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 11, 2021

/label remove hotspot /csr needed

@rkennke A CSR request is needed here for the change to the UseHeavyMonitors flag, which for historical reasons was a product flag. I wonder if anyone using interpreter-only Zero builds uses this flag?

I filed CSR here:
https://bugs.openjdk.java.net/browse/JDK-8277025

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 11, 2021

How was, and going forward will, this be tested? There are no tests using UseHeavyMonitors. And a real test would be to run a bunch of other tests with the flag applied.

I have run tier1-4 with the flag explicitely enabled. However, I agree, we should include the flag in a run config for some relevant tests. Do you have any suggestions? Maybe we have a stress test for synchronized already, and could add a run config there? jcstress comes to mind, but I am not sure if the included jcstress tests even exercise synchronized (rather than j.u.c. stuff)?

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Nov 12, 2021

I know nothing about jcstress but I skimmed through it and it seems synchronized is covered in "CHAPTER 2.c". I don't know how we normally run jcstress, but I don't think there is any file that would allow you set the flag. It would really be up to the person running the tests to add a configuration that includes testing UseHeavyMonitors. We have test configuration files that would do that, but I don't think we can add it to our testing due to resource constraints. So I guess we need at least some minimal tier1 test that does a bit of synchronization with UseHeavyMonitors enabled so that we can avoid breaking it.

@dcubed-ojdk
Copy link
Member

@dcubed-ojdk dcubed-ojdk commented Nov 12, 2021

@lmesnik - Can you chime in the testing of this cmd line option?

@lmesnik
Copy link
Member

@lmesnik lmesnik commented Nov 12, 2021

The testing VM options are set in task definitions. I'll file a separate issue to adjust configs.

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 12, 2021

The testing VM options are set in task definitions. I'll file a separate issue to adjust configs.

This is not necessary. I only need one or a few tests that exercise synchronize statement, and run this with -XX:+UseHeavyMonitors. If no such test exists, then I'll make one.

@lmesnik
Copy link
Member

@lmesnik lmesnik commented Nov 12, 2021

@rkennke thanks, I don't see any good specific tests to run openjdk regression suite. There are a bunch of tests in JCK, jcstress. You could also just run tier1 with UseHeavyMonitors as a sanity check. There are also jvmti tests that might be used to verify that JVMTI is not broken with UseHeavyMonitors.

@reinrich
Copy link
Contributor

@reinrich reinrich commented Nov 17, 2021

Wouldn't a (new) minimal multi-threaded test that explicitly sets UseHeavyMonitors be good and sufficient for this develop feature?

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 30, 2021

HI Roman,

I have a number of initial comments/suggestions/requests - see below.

IIUC you are only making UseHeavyMonitors work properly on x86_64, but in that case you cannot convert UseFastLocks to UseHeavyMonitors on all platforms as it won't work correctly on those other platforms.

Cheers, David

It would not break as such on other platforms. It would only be partially implemented, that is C1 would emit calls to runtime for and only use monitors while interpreter and C2 would still emit stack locks. That is ok - and that is roughly what +UseFastLocking used to do.

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Nov 30, 2021

I have addressed the suggested changes, and also implemented (and verified) the flag on x86_32 and aarch64. I don't have access to the remaining CPU arches. Can I please get another round of reviews? Thanks, Roman

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Dec 1, 2021

IIUC you are only making UseHeavyMonitors work properly on x86_64, but in that case you cannot convert UseFastLocks to UseHeavyMonitors on all platforms as it won't work correctly on those other platforms.
Cheers, David

It would not break as such on other platforms. It would only be partially implemented, that is C1 would emit calls to runtime for and only use monitors while interpreter and C2 would still emit stack locks. That is ok - and that is roughly what +UseFastLocking used to do.

Sorry but I don't see how having the interpreter+C2 use stack-locks while C1 ignores them can possibly be correct. ???

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Dec 1, 2021

IIUC you are only making UseHeavyMonitors work properly on x86_64, but in that case you cannot convert UseFastLocks to UseHeavyMonitors on all platforms as it won't work correctly on those other platforms.
Cheers, David

It would not break as such on other platforms. It would only be partially implemented, that is C1 would emit calls to runtime for and only use monitors while interpreter and C2 would still emit stack locks. That is ok - and that is roughly what +UseFastLocking used to do.

Sorry but I don't see how having the interpreter+C2 use stack-locks while C1 ignores them can possibly be correct. ???

Ok, right. It worked before, because -UseFastLocking (C1) and +UseHeavyMonitors (interpreter) would generate runtime calls (instead of fast stack locking paths), and the runtime implementation would still do stack-locking.

For arches where UseHeavyMonitors is not (fully) supported, I am fixing this by letting the runtime do stack-locks.

TBH, it would be nice if this change could be properly implemented on remaining arches... (ping @TheRealMDoerr for PPC, not sure who could do arm or s390).

@TheRealMDoerr
Copy link
Contributor

@TheRealMDoerr TheRealMDoerr commented Dec 1, 2021

PPC64 could be implemented like this:

diff --git a/src/hotspot/cpu/ppc/ppc.ad b/src/hotspot/cpu/ppc/ppc.ad
index 958059e1ca2..dc96bd15836 100644
--- a/src/hotspot/cpu/ppc/ppc.ad
+++ b/src/hotspot/cpu/ppc/ppc.ad
@@ -12132,7 +12132,7 @@ instruct partialSubtypeCheck(iRegPdst result, iRegP_N2P subklass, iRegP_N2P supe
 instruct cmpFastLock(flagsReg crx, iRegPdst oop, iRegPdst box, iRegPdst tmp1, iRegPdst tmp2) %{
   match(Set crx (FastLock oop box));
   effect(TEMP tmp1, TEMP tmp2);
-  predicate(!Compile::current()->use_rtm());
+  predicate(!Compile::current()->use_rtm() && !UseHeavyMonitors);
 
   format %{ "FASTLOCK  $oop, $box, $tmp1, $tmp2" %}
   ins_encode %{
@@ -12149,7 +12149,7 @@ instruct cmpFastLock(flagsReg crx, iRegPdst oop, iRegPdst box, iRegPdst tmp1, iR
 instruct cmpFastLock_tm(flagsReg crx, iRegPdst oop, rarg2RegP box, iRegPdst tmp1, iRegPdst tmp2, iRegPdst tmp3) %{
   match(Set crx (FastLock oop box));
   effect(TEMP tmp1, TEMP tmp2, TEMP tmp3, USE_KILL box);
-  predicate(Compile::current()->use_rtm());
+  predicate(Compile::current()->use_rtm() && !UseHeavyMonitors);
 
   format %{ "FASTLOCK  $oop, $box, $tmp1, $tmp2, $tmp3 (TM)" %}
   ins_encode %{
@@ -12165,6 +12165,18 @@ instruct cmpFastLock_tm(flagsReg crx, iRegPdst oop, rarg2RegP box, iRegPdst tmp1
   ins_pipe(pipe_class_compare);
 %}
 
+instruct cmpFastLock_hm(flagsReg crx, iRegPdst oop, rarg2RegP box) %{
+  match(Set crx (FastLock oop box));
+  predicate(UseHeavyMonitors);
+
+  format %{ "FASTLOCK  $oop, $box (HM)" %}
+  ins_encode %{
+    // Set NE to indicate 'failure' -> take slow-path.
+    __ crandc($crx$$CondRegister, Assembler::equal, $crx$$CondRegister, Assembler::equal);
+  %}
+  ins_pipe(pipe_class_compare);
+%}
+
 instruct cmpFastUnlock(flagsReg crx, iRegPdst oop, iRegPdst box, iRegPdst tmp1, iRegPdst tmp2, iRegPdst tmp3) %{
   match(Set crx (FastUnlock oop box));
   effect(TEMP tmp1, TEMP tmp2, TEMP tmp3);
diff --git a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
index a834fa1af36..bac8ef164f8 100644
--- a/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
+++ b/src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
@@ -2014,8 +2014,10 @@ nmethod *SharedRuntime::generate_native_wrapper(MacroAssembler *masm,
 
     // Try fastpath for locking.
     // fast_lock kills r_temp_1, r_temp_2, r_temp_3.
-    __ compiler_fast_lock_object(r_flag, r_oop, r_box, r_temp_1, r_temp_2, r_temp_3);
-    __ beq(r_flag, locked);
+    if (!UseHeavyMonitors) {
+      __ compiler_fast_lock_object(r_flag, r_oop, r_box, r_temp_1, r_temp_2, r_temp_3);
+      __ beq(r_flag, locked);
+    }
 
     // None of the above fast optimizations worked so we have to get into the
     // slow case of monitor enter. Inline a special case of call_VM that
diff --git a/src/hotspot/share/runtime/synchronizer.cpp b/src/hotspot/share/runtime/synchronizer.cpp
index 4c5ea4a6e40..4f9c7c21a9b 100644
--- a/src/hotspot/share/runtime/synchronizer.cpp
+++ b/src/hotspot/share/runtime/synchronizer.cpp
@@ -418,7 +418,7 @@ void ObjectSynchronizer::handle_sync_on_value_based_class(Handle obj, JavaThread
 }
 
 static bool useHeavyMonitors() {
-#if defined(X86) || defined(AARCH64)
+#if defined(X86) || defined(AARCH64) || defined(PPC64)
   return UseHeavyMonitors;
 #else
   return false;

I don't like hacking the regular assembler implementations. Better would be to change C2 such that it doesn't generate FastLockNodes. But that may be a bit cumbersome.

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Dec 1, 2021

Thank you, Martin!

I don't like hacking the regular assembler implementations. Better would be to change C2 such that it doesn't generate FastLockNodes. But that may be a bit cumbersome.

That is a good suggestion, and would help ease the work in the backend.

I believe you still have to change something in sharedRuntime_ppc.cpp, similar to what I did in, e.g., sharedRuntime_aarch64.cpp.

@TheRealMDoerr
Copy link
Contributor

@TheRealMDoerr TheRealMDoerr commented Dec 1, 2021

I believe you still have to change something in sharedRuntime_ppc.cpp, similar to what I did in, e.g., sharedRuntime_aarch64.cpp.

You mean in generate_native_wrapper? I already did. It uses the same assembler function as C2 on PPC64. Did I miss anything else? I think hacking unlock is optional. The additional checks don't really disturb.

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Dec 1, 2021

I believe you still have to change something in sharedRuntime_ppc.cpp, similar to what I did in, e.g., sharedRuntime_aarch64.cpp.

You mean in generate_native_wrapper? I already did. It uses the same assembler function as C2 on PPC64. Did I miss anything else? I think hacking unlock is optional. The additional checks don't really disturb.

Ah I haven't seen it, sorry.
It turns out, I cannot avoid emitting FastLockNode, some backends (x86 and aarch64) also generate fast-path code that deals with ObjectMonitor, and we want this even when running with +UseHeavyMonitors.

Can you verify the new testcase, and perhaps some test programs that do some locking with -XX:+UseHeavyMonitors -XX:+VerifyHeavyMonitors ? You also need to include PPC in arguments.cpp and synchronizer.cpp changes to enable that stuff on PPC:

@TheRealMDoerr
Copy link
Contributor

@TheRealMDoerr TheRealMDoerr commented Dec 2, 2021

It turns out, I cannot avoid emitting FastLockNode, some backends (x86 and aarch64) also generate fast-path code that deals with ObjectMonitor, and we want this even when running with +UseHeavyMonitors.

Ok, thanks for checking. You have convinced me that your version is fine. We should do it the same way on PPC64:

diff --git a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
index 98565003691..cb58e775422 100644
--- a/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
+++ b/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
@@ -2660,27 +2660,32 @@ void MacroAssembler::compiler_fast_lock_object(ConditionRegister flag, Register
   andi_(temp, displaced_header, markWord::monitor_value);
   bne(CCR0, object_has_monitor);
 
-  // Set displaced_header to be (markWord of object | UNLOCK_VALUE).
-  ori(displaced_header, displaced_header, markWord::unlocked_value);
-
-  // Load Compare Value application register.
-
-  // Initialize the box. (Must happen before we update the object mark!)
-  std(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
-
-  // Must fence, otherwise, preceding store(s) may float below cmpxchg.
-  // Compare object markWord with mark and if equal exchange scratch1 with object markWord.
-  cmpxchgd(/*flag=*/flag,
-           /*current_value=*/current_header,
-           /*compare_value=*/displaced_header,
-           /*exchange_value=*/box,
-           /*where=*/oop,
-           MacroAssembler::MemBarRel | MacroAssembler::MemBarAcq,
-           MacroAssembler::cmpxchgx_hint_acquire_lock(),
-           noreg,
-           &cas_failed,
-           /*check without membar and ldarx first*/true);
-  assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
+  if (!UseHeavyMonitors) {
+    // Set displaced_header to be (markWord of object | UNLOCK_VALUE).
+    ori(displaced_header, displaced_header, markWord::unlocked_value);
+
+    // Load Compare Value application register.
+
+    // Initialize the box. (Must happen before we update the object mark!)
+    std(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
+
+    // Must fence, otherwise, preceding store(s) may float below cmpxchg.
+    // Compare object markWord with mark and if equal exchange scratch1 with object markWord.
+    cmpxchgd(/*flag=*/flag,
+             /*current_value=*/current_header,
+             /*compare_value=*/displaced_header,
+             /*exchange_value=*/box,
+             /*where=*/oop,
+             MacroAssembler::MemBarRel | MacroAssembler::MemBarAcq,
+             MacroAssembler::cmpxchgx_hint_acquire_lock(),
+             noreg,
+             &cas_failed,
+             /*check without membar and ldarx first*/true);
+    assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
+  } else {
+    // Set NE to indicate 'failure' -> take slow-path.
+    crandc(flag, Assembler::equal, flag, Assembler::equal);
+  }
 
   // If the compare-and-exchange succeeded, then we found an unlocked
   // object and we have now locked it.
@@ -2768,12 +2773,14 @@ void MacroAssembler::compiler_fast_unlock_object(ConditionRegister flag, Registe
   }
 #endif
 
-  // Find the lock address and load the displaced header from the stack.
-  ld(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
+  if (!UseHeavyMonitors) {
+    // Find the lock address and load the displaced header from the stack.
+    ld(displaced_header, BasicLock::displaced_header_offset_in_bytes(), box);
 
-  // If the displaced header is 0, we have a recursive unlock.
-  cmpdi(flag, displaced_header, 0);
-  beq(flag, cont);
+    // If the displaced header is 0, we have a recursive unlock.
+    cmpdi(flag, displaced_header, 0);
+    beq(flag, cont);
+  }
 
   // Handle existing monitor.
   // The object has an existing monitor iff (mark & monitor_value) != 0.
@@ -2782,20 +2789,24 @@ void MacroAssembler::compiler_fast_unlock_object(ConditionRegister flag, Registe
   andi_(R0, current_header, markWord::monitor_value);
   bne(CCR0, object_has_monitor);
 
-  // Check if it is still a light weight lock, this is is true if we see
-  // the stack address of the basicLock in the markWord of the object.
-  // Cmpxchg sets flag to cmpd(current_header, box).
-  cmpxchgd(/*flag=*/flag,
-           /*current_value=*/current_header,
-           /*compare_value=*/box,
-           /*exchange_value=*/displaced_header,
-           /*where=*/oop,
-           MacroAssembler::MemBarRel,
-           MacroAssembler::cmpxchgx_hint_release_lock(),
-           noreg,
-           &cont);
-
-  assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
+  if (!UseHeavyMonitors) {
+    // Check if it is still a light weight lock, this is is true if we see
+    // the stack address of the basicLock in the markWord of the object.
+    // Cmpxchg sets flag to cmpd(current_header, box).
+    cmpxchgd(/*flag=*/flag,
+             /*current_value=*/current_header,
+             /*compare_value=*/box,
+             /*exchange_value=*/displaced_header,
+             /*where=*/oop,
+             MacroAssembler::MemBarRel,
+             MacroAssembler::cmpxchgx_hint_release_lock(),
+             noreg,
+             &cont);
+    assert(oopDesc::mark_offset_in_bytes() == 0, "offset of _mark is not 0");
+  } else {
+    // Set NE to indicate 'failure' -> take slow-path.
+    crandc(flag, Assembler::equal, flag, Assembler::equal);
+  }
 
   // Handle existing monitor.
   b(cont);
diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
index 3396adc0799..969c8e82b91 100644
--- a/src/hotspot/share/runtime/arguments.cpp
+++ b/src/hotspot/share/runtime/arguments.cpp
@@ -2021,12 +2021,12 @@ bool Arguments::check_vm_args_consistency() {
   }
 #endif
 
-#if !defined(X86) && !defined(AARCH64)
+#if !defined(X86) && !defined(AARCH64) && !defined(PPC64)
   if (UseHeavyMonitors) {
     warning("UseHeavyMonitors is not fully implemented on this architecture");
   }
 #endif
-#ifdef X86
+#if defined(X86) || defined(PPC64)
   if (UseHeavyMonitors && UseRTMForStackLocks) {
     fatal("-XX:+UseHeavyMonitors and -XX:+UseRTMForStackLocks are mutually exclusive");
   }
diff --git a/src/hotspot/share/runtime/synchronizer.cpp b/src/hotspot/share/runtime/synchronizer.cpp
index 4c5ea4a6e40..4f9c7c21a9b 100644
--- a/src/hotspot/share/runtime/synchronizer.cpp
+++ b/src/hotspot/share/runtime/synchronizer.cpp
@@ -418,7 +418,7 @@ void ObjectSynchronizer::handle_sync_on_value_based_class(Handle obj, JavaThread
 }
 
 static bool useHeavyMonitors() {
-#if defined(X86) || defined(AARCH64)
+#if defined(X86) || defined(AARCH64) || defined(PPC64)
   return UseHeavyMonitors;
 #else
   return false;
diff --git a/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java b/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
index cd32e222f68..922b18836dd 100644
--- a/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
+++ b/test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
@@ -48,7 +48,7 @@
 /*
  * @test
  * @summary Exercise multithreaded maps, using only heavy monitors.
- * @requires os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64" | os.arch=="aarch64"
+ * @requires os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64" | os.arch=="aarch64" | os.arch == "ppc64" | os.arch == "ppc64le"
  * @library /test/lib
  * @run main/othervm/timeout=1600 -XX:+IgnoreUnrecognizedVMOptions -XX:+UseHeavyMonitors -XX:+VerifyHeavyMonitors MapLoops
  */

Note that this version does no longer require changes in sharedRuntime_ppc because the native wrapper generator uses the same code as C2. The test case has passed.

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Dec 2, 2021

Thanks, @TheRealMDoerr ! I've added your PPC port to this PR.

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Dec 6, 2021

Can I get more reviews for this PR before the JDK18 window closes? I suggest to not wait for arm or s390 ports for now. Thanks!

Copy link
Contributor

@TheRealMDoerr TheRealMDoerr left a comment

This version LGTM.

Copy link
Member

@dcubed-ojdk dcubed-ojdk left a comment

Thumbs up. I'm going to kick off some Mach5 testing for
this change or at least try to...

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Dec 6, 2021

Thumbs up. I'm going to kick off some Mach5 testing for this change or at least try to...

Alright, I will wait for it! Thanks for testing!

@dcubed-ojdk
Copy link
Member

@dcubed-ojdk dcubed-ojdk commented Dec 7, 2021

Mach5 Tier1:

  • dcubed-8276901_for_jdk18.git-20211206-1656-26967213
  • no test failures

Mach5 Tier2:

  • dcubed-8276901_for_jdk18.git-20211206-2009-26973681
  • 2 known, unrelated test failures

Mach5 Tier3:

  • dcubed-8276901_for_jdk18.git-20211206-2009-26973700
  • no failures

Mach5 Tier4:

  • dcubed-8276901_for_jdk18.git-20211206-2124-26976450
  • 11 known, unrelated test failures

Mach5 Tier5:

  • dcubed-8276901_for_jdk18.git-20211206-2125-26976484
  • 3 known, unrelated failures

Mach5 Tier6:

  • dcubed-8276901_for_jdk18.git-20211206-2220-26978292
  • no failures

Mach5 Tier7:

  • dcubed-8276901_for_jdk18.git-20211207-0044-26982843
  • 2 known, unrelated failures

Mach5 Tier8:

  • dcubed-8276901_for_jdk18.git-20211207-0045-26982871
  • 1 known, unrelated failure

So Tier[1-4] are complete and look fine. Mach5 is a bit over loaded at the
moment so Tier[5-8] are still running. I think the Tier[1-4] results and the
partial Tier[5-8] are good enough to say that these bits are okay.

Update: Tier[5-8] finished and the results still look good.

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Dec 7, 2021

So Tier[1-4] are complete and look fine. Mach5 is a bit over loaded at the moment so Tier[5-8] are still running. I think the Tier[1-4] results and the partial Tier[5-8] are good enough to say that these bits are okay.

Thanks, David! I will then go ahead and integrate this PR.

Cheers,
Roman

@rkennke
Copy link
Contributor Author

@rkennke rkennke commented Dec 7, 2021

/integrate

@openjdk
Copy link

@openjdk openjdk bot commented Dec 7, 2021

Going to push as commit 5b81d5e.
Since your change was applied there have been 161 commits pushed to the master branch:

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot closed this Dec 7, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Dec 7, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Dec 7, 2021

@rkennke Pushed as commit 5b81d5e.

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

@rkennke rkennke deleted the JDK-8276901 branch Dec 7, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Dec 9, 2021

Mailing list message from David Holmes on hotspot-runtime-dev:

(re-sending for the mailing lists as previous mail seems lost)

On 8/12/2021 12:40 am, Roman Kennke wrote:

On Tue, 7 Dec 2021 14:34:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

So Tier[1-4] are complete and look fine. Mach5 is a bit over loaded at the moment so Tier[5-8] are still running. I think the Tier[1-4] results and the partial Tier[5-8] are good enough to say that these bits are okay.

Thanks, David! I will then go ahead and integrate this PR.

That was Daniel not David.

Sorry I didn't get back to this sooner but ...

I am not happy with the argument processing in
Arguments::check_vm_args_consistency. This method does not call fatal(),
it reports a warning or error message and returns false if VM
initialization should not continue. Also for platforms where
UseHeavyMonitors is not fully implemented it should not just be a
warning IMO but also cause initialization to not continue. If we are
going to return false then the error message should go to the error
stream not be issued as a warning(). Please file a fillow up issue and
fix this.

I remain concerned about the impact of this change on platforms that
don't support UseHeavyMonitors fully.

David

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-compiler hotspot-runtime integrated
7 participants