RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines

[Coleen Phillimore]

On Thu, 18 Mar 2021 12:58:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The intent is that THREAD, ideally, is only used in relation to exception throwing/catching and you can't tell that if you use it just for convenience everywhere else. I haven't introduced a new local "thread" when there is only a single use, but if there are multiple uses then using "thread" or "current" is IMO much clearer because we can clearly isolate the the code that relates to exceptions and the code that does not. That is what I'm trying to achieve here. It wont be perfect and not every use of THREAD will be replaced, but it will be a great improvement over what we currently have.
>> In this code I would love to change "thread" to "current" but the JRT macros require the use of "thread" and changing that would be too big a change. Note that in the code above I'm not introducing "thread" it is already there.
>
> Correction, sorry I was misled by the mis-quoted code in the discussion view, I do introduce the local here because there are multiple none-exception-related uses.

I don't find passing "thread" cleaner than THREAD in these cases.  We *know* THREAD is the current thread and these functions pass it as the leading parameter is not confusing at all.  These patterns: of Handle(THREAD, obj), MutexLocker ml(THREAD, lock), and methodHandle method(THREAD, m); appear everywhere. I put many of them there to pass the current thread parameter.  Changing these patterns is a huge amount of churn for no benefit to me at least.  I don't think I want to hunt around for a 'thread' that I hope is the current thread.  I will use THREAD when needed.
Most of these changes seem harmless but I object to introducing a 'thread' just to avoid passing THREAD.

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

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