RFR: 8253694: Remove Thread::muxAcquire() from ThreadCrashProtection() [v2]

[Patricio Chilano Mateo]

On Wed, 30 Sep 2020 14:05:36 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

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

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.

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

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