RFR: 8263709: Cleanup THREAD/TRAPS/CHECK usage in JRT_ENTRY routines
David Holmes
david.holmes at oracle.com
Sun Mar 21 13:17:59 UTC 2021
On 19/03/2021 10:00 pm, Coleen Phillimore wrote:
> On Fri, 19 Mar 2021 01:48:47 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
>
>>> All JRT_ENTRY routines are required to have a parameter, "JavaThread* thread", which must be the current thread. The JRT_ENTRY, and related macros, then use this parameter and also expose it as THREAD for use with exception macros. But the fact "thread" is the current thread is lost in some routines and we see strange calls to other code that pass both "thread" and "THREAD" as distinct parameters - primarily when a TRAPS method is involved.
>>>
>>> This should be cleaned up along with a general check on misuse of TRAPS/THREAD.
>>>
>>> Testing: tiers 1-3
>>>
>>> Thanks,
>>> David
>>
>> Changes requested by coleenp (Reviewer).
>
> I thought the purpose of this work was to make TRAPS and the JRT/JVM_ENTRY macros take JavaThread instead of Thread.
> ie #define TRAPS JavaThread* THREAD
That is the endgame for JDK-8252685. The current issue is a step along
the way to make that one more digestible. The entry macros already work
with the current JavaThread:
- JRT_ENTRY uses the "thread" parameter of the wrapped method
- JVM_ENTRY and JNI_ENTRY extract it from the JNIEnv
and in all cases they then declare an alias:
Thread* THREAD = thread;
for use with TRAPS/CHECK
David
-----
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/3062
>
More information about the hotspot-runtime-dev
mailing list