RFR: 8252685: APIs that require JavaThread should take JavaThread arguments

Coleen Phillimore coleenp at openjdk.java.net
Mon May 10 12:35:52 UTC 2021


On Sun, 9 May 2021 22:42:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/sharedRuntime.cpp line 1197:
>> 
>>> 1195: 
>>> 1196: methodHandle SharedRuntime::find_callee_method(TRAPS) {
>>> 1197:   JavaThread* current = THREAD;
>> 
>> I think these look strange, especially the ones
>> JavaThread* thread = THREAD;
>> but they can be fixed later to just use THREAD when THREAD is available. And it's not really important.
>
> They are the inverse of the
> 
> JavaThread* THREAD = current; // For exception macro use.
> 
> due to the general trend to not use THREAD for non-exception related code except in some trivial cases.

I know what they are.  I think if we already have a THREAD then there's no point having another thread or current variable and it's noisy and confusing, ie. we *know* that THREAD is the current thread by definition and 'current' seems to suggest by name but no guarantee of that, and 'thread' is just generic and means nothing.  I don't think there should be another variable introduced for Handles and ResourceMarks.  Using another variable for last_frame and such might make some sense.  Anyway, my definition of "trivial" cases might be more broad than yours.
It's not for this change, though, this change is fine, even though I think these extra declarations should be removed at some later date if the code changes for some other reason.

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

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


More information about the serviceability-dev mailing list