8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() #376

pchilano · 2020-09-28T06:07:58Z

Hi all,

Please review the following patch. Current ThreadCrashProtection() implementation uses static members which requires the use of Thread::muxAcquire() to allow only one user at a time. We can avoid this synchronization requirement if each thread has its own ThreadCrashProtection *data.
I tested it builds on Linux, macOS and Windows. Since the JfrThreadSampler is the only one using this I run all the tests from test/jdk/jdk/jfr/. I also run some tests with JFR enabled while forcing a crash in OSThreadSampler::protected_task() and tests passed with several "Thread method sampler crashed" UL output. Also run tiers1-3.

Thanks,
Patricio

Progress

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

Issue

JDK-8253694: Remove Thread::muxAcquire() from ThreadCrashProtection()

Reviewers

David Holmes (@dholmes-ora - Reviewer)
Daniel D. Daugherty (@dcubed-ojdk - Reviewer)
Coleen Phillimore (@coleenp - Reviewer) ⚠️ Review applies to c3168cc

Download

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

bridgekeeper · 2020-09-28T06:10:07Z

👋 Welcome back pchilanomate! 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-28T06:11:23Z

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

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.

pchilano · 2020-09-28T06:24:54Z

/label add hotspot-jfr

openjdk · 2020-09-28T06:25:49Z

@pchilano
The hotspot-jfr label was successfully added.

mlbridge · 2020-09-28T14:24:28Z

Webrevs

coleenp · 2020-09-28T15:00:20Z

src/hotspot/share/runtime/thread.hpp

+    }
+  }
+#endif
+


Could this be pushed down into osThread ?

Yes, it can but it's not that clean I think given the osthread indirections. Here's how it looks: pchilano@73a41ad

I think another alternative could be to remove the "#ifndef _WINDOWS" clause and define an empty check_crash_protection() method in os_windows.hpp

Ok, yes, I saw the ifdef WINDOWS and thought it should be more os platform specific, but if you had an empty method in os_windows.hpp that would be better imo. It's not as nice in osthread. Thank you for considering it.

dholmes-ora

Hi Patricio,

This seems fine, but I'm wondering what the motivation for this change was? Adding more per-thread state is arguably just adding to the clutter of per-thread state. I don't know if this approach was considered when @robehn fixed JDK-8183925.

Thanks,
David

robehn · 2020-09-30T06:51:41Z

I don't think so.

I have not seen crash protection catching anything since pre-JDK 9. (we did a lot of fixes to the stack-walking code)
I would remove it completely instead :) Not sure what JFR team says...

mgronlun · 2020-09-30T09:53:52Z

Like David I would also like to know more about the motivation. Is the feature expected to be used by a larger number of threads? If so, there might be concerns about scalability that was not considered initially.

I agree that we have seen less, and for a long time almost no, asserts related to thread sampling in our testing with fastdebug builds (only product builds run with the protection). At the same time, I am not sure how representative that is considering all the code that is out there. We should also keep in mind that we have upcoming features that will have slightly different stack layouts which will affect how stackwalking is achieved, so I would recommend keeping the established safety mechanism.

pchilano · 2020-09-30T14:05:36Z

I looked at the users of Thread::muxAcquire/muxRelease and this was one of the two places where it is used. If we are going to have a crash protection mechanism for general use then the fields should not be static. Now, if we know only the JfrThreadSampler uses it and we want to optimize away that pointer in the thread object then that makes sense, but then we should remove _crash_mux.

pchilano · 2020-10-05T15:00:26Z

Please see the update. Since there was concern about adding a new pointer in the Thread class I kept the fields as static and just removed _crash_mux. I also fixed the comment about the class being used by the JfrSampler instead of the Watcher thread.

dcubed-ojdk

Looks good. I only have minor suggested changes, but it's your call
on whether to make those changes.

dcubed-ojdk · 2020-10-05T15:58:48Z

src/hotspot/os/posix/os_posix.cpp

+  assert(Thread::current()->is_JfrSampler_thread(), "should be JFRSampler");
+  _protected_thread = Thread::current();


Perhaps this:
_protected_thread = Thread::current();
assert(_protected_thread->is_JfrSampler_thread(), "should be JFRSampler");
would be a little more clean.

dcubed-ojdk · 2020-10-05T16:00:15Z

src/hotspot/os/windows/os_windows.cpp

+  assert(Thread::current()->is_JfrSampler_thread(), "should be JFRSampler");
+  _protected_thread = Thread::current();


Perhaps this:
_protected_thread = Thread::current();
assert(_protected_thread->is_JfrSampler_thread(), "should be JFRSampler");
would be a little more clean.

openjdk · 2020-10-05T16:02:59Z

@pchilano 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 more details.

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

8253694: Remove Thread::muxAcquire() from ThreadCrashProtection()

Reviewed-by: dholmes, dcubed, coleenp

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 116 new commits pushed to the master branch:

4fe68f5: 8253426: jpackage is unable to generate working EXE for add-launcher configurations
c9d0407: 8253794: TestAbortVMOnSafepointTimeout never timeouts
f2f77f7: 8253761: Wrong URI syntax printed by jar --describe-module
b29e108: 8253944: Certain method references to VarHandle methods should fail
88d75c9: 8156071: List.of: reduce array copying during creation
ea27a54: 8224509: Incorrect alignment in CDS related allocation code on 32-bit platforms
4d29116: 8253433: Remove -XX:+Debugging product option
81dae70: 8253948: Memory leak in ImageFileReader
65cab55: 8253971: ZGC: Flush mark stacks after processing concurrent roots
19219a9: 8253960: Memory leak in Java_java_lang_ClassLoader_defineClass0()
... and 106 more: https://git.openjdk.java.net/jdk/compare/f014854ac71a82b307667ba017f01b13eed54330...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.

pchilano · 2020-10-05T18:26:30Z

Looks good. I only have minor suggested changes, but it's your call
on whether to make those changes.

Thanks Dan! Updated.

dcubed-ojdk

Thumbs up.

coleenp

LGTM!

coleenp · 2020-09-28T21:48:09Z

src/hotspot/share/runtime/thread.hpp

+    }
+  }
+#endif
+


Ok, yes, I saw the ifdef WINDOWS and thought it should be more os platform specific, but if you had an empty method in os_windows.hpp that would be better imo. It's not as nice in osthread. Thank you for considering it.

dholmes-ora

So let me see if I've got this straight. Prior to JDK-8183925 CrashProtection was exclusively for the WatcherThread. JDK-8183925 generalized that to allow any(?) thread to use it. Now as the only client is the JfrSampler thread we are making crash protection exclusively only available to it.

pchilano · 2020-10-06T03:25:53Z

So let me see if I've got this straight. Prior to JDK-8183925 CrashProtection was exclusively for the WatcherThread. JDK-8183925 generalized that to allow any(?) thread to use it. Now as the only client is the JfrSampler thread we are making crash protection exclusively only available to it.

Exactly.

pchilano · 2020-10-06T03:28:51Z

Thanks @dcubed-ojdk, @coleenp and @dholmes-ora for the reviews.

pchilano · 2020-10-06T14:46:56Z

/integrate

openjdk · 2020-10-06T14:49:10Z

@pchilano Since your change was applied there have been 124 commits pushed to the master branch:

d2b1dc6: 8254054: Pre-submit testing using GitHub Actions should not use the deprecated set-env command
a34f48b: 8253832: CharsetDecoder : decode() mentioning CoderMalfunctionError behavior not as per spec
f397b60: 8251123: doclint warnings about missing javadoc tags and comments
c9d1dcc: 8253902: G1: Starting a new marking cycle before the conc mark thread fully completed causes assertion failure
9199783: 8253565: PPC64: Fix duplicate if condition in vm_version_ppc.cpp
1728547: 8254010: GrowableArrayView::print fails to compile
6e61861: 8254046: Remove double semicolon introduced by JDK-8235521
5d84e95: 8204256: improve jlink error message to report unsupported class file format
4fe68f5: 8253426: jpackage is unable to generate working EXE for add-launcher configurations
c9d0407: 8253794: TestAbortVMOnSafepointTimeout never timeouts
... and 114 more: https://git.openjdk.java.net/jdk/compare/f014854ac71a82b307667ba017f01b13eed54330...master

Your commit was automatically rebased without conflicts.

Pushed as commit 57493c1.

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

v1

c3168cc

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

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

pchilano marked this pull request as ready for review September 28, 2020 14:02

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

coleenp reviewed Sep 28, 2020

View reviewed changes

dholmes-ora reviewed Sep 30, 2020

View reviewed changes

Remove _crash_mux

00539d6

dcubed-ojdk approved these changes Oct 5, 2020

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Oct 5, 2020

Address Dan's comments

b93e94b

dcubed-ojdk approved these changes Oct 5, 2020

View reviewed changes

coleenp approved these changes Oct 5, 2020

View reviewed changes

dholmes-ora approved these changes Oct 5, 2020

View reviewed changes

openjdk bot closed this Oct 6, 2020

openjdk bot added the integrated Pull request has been integrated label Oct 6, 2020

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Oct 6, 2020

pchilano deleted the 8253694-threadcrashprotection branch November 16, 2020 03:03

8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() #376

8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() #376

pchilano commented Sep 28, 2020 •

edited by openjdk bot

bridgekeeper bot commented Sep 28, 2020

openjdk bot commented Sep 28, 2020

pchilano commented Sep 28, 2020

openjdk bot commented Sep 28, 2020

mlbridge bot commented Sep 28, 2020 •

edited

coleenp Sep 28, 2020

pchilano Sep 28, 2020

coleenp Sep 28, 2020

dholmes-ora left a comment

robehn commented Sep 30, 2020 •

edited

mgronlun commented Sep 30, 2020

pchilano commented Sep 30, 2020

pchilano commented Oct 5, 2020

dcubed-ojdk left a comment •

edited

dcubed-ojdk Oct 5, 2020

dcubed-ojdk Oct 5, 2020

openjdk bot commented Oct 5, 2020 •

edited

pchilano commented Oct 5, 2020

dcubed-ojdk left a comment

coleenp left a comment

coleenp Sep 28, 2020

dholmes-ora left a comment

pchilano commented Oct 6, 2020

pchilano commented Oct 6, 2020

pchilano commented Oct 6, 2020

openjdk bot commented Oct 6, 2020

		assert(Thread::current()->is_JfrSampler_thread(), "should be JFRSampler");
		_protected_thread = Thread::current();

8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() #376

8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() #376

Conversation

pchilano commented Sep 28, 2020 • edited by openjdk bot

Progress

Issue

Reviewers

Download

bridgekeeper bot commented Sep 28, 2020

openjdk bot commented Sep 28, 2020

pchilano commented Sep 28, 2020

openjdk bot commented Sep 28, 2020

mlbridge bot commented Sep 28, 2020 • edited

Webrevs

coleenp Sep 28, 2020

Choose a reason for hiding this comment

pchilano Sep 28, 2020

Choose a reason for hiding this comment

coleenp Sep 28, 2020

Choose a reason for hiding this comment

dholmes-ora left a comment

Choose a reason for hiding this comment

robehn commented Sep 30, 2020 • edited

mgronlun commented Sep 30, 2020

pchilano commented Sep 30, 2020

pchilano commented Oct 5, 2020

dcubed-ojdk left a comment • edited

Choose a reason for hiding this comment

dcubed-ojdk Oct 5, 2020

Choose a reason for hiding this comment

dcubed-ojdk Oct 5, 2020

Choose a reason for hiding this comment

openjdk bot commented Oct 5, 2020 • edited

pchilano commented Oct 5, 2020

dcubed-ojdk left a comment

Choose a reason for hiding this comment

coleenp left a comment

Choose a reason for hiding this comment

coleenp Sep 28, 2020

Choose a reason for hiding this comment

dholmes-ora left a comment

Choose a reason for hiding this comment

pchilano commented Oct 6, 2020

pchilano commented Oct 6, 2020

pchilano commented Oct 6, 2020

openjdk bot commented Oct 6, 2020

pchilano commented Sep 28, 2020 •

edited by openjdk bot

mlbridge bot commented Sep 28, 2020 •

edited

robehn commented Sep 30, 2020 •

edited

dcubed-ojdk left a comment •

edited

openjdk bot commented Oct 5, 2020 •

edited