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

[Patricio Chilano Mateo]

On Wed, 30 Sep 2020 09:53:52 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> 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...
>
> 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.

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.

-------------

PR: https://git.openjdk.java.net/jdk/pull/376