RFR(XL): 8167108 - SMR and JavaThread Lifecycle

[Erik Österlund]

Hi,

Some replies...

On 2017-11-21 18:36, Daniel D. Daugherty wrote:
> Thanks for keeping all the OpenJDK aliases!
>
>
> On 11/21/17 12:24 PM, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 11/21/17 11:28 AM, Daniel D. Daugherty wrote:
>>>
>>> On 11/20/17 3:12 PM, coleen.phillimore at oracle.com wrote:
>>>
>>>> I can't find the caller of threads_do_smr.
>>>
>>> I'm guessing that's used by the GC code that depends on Thread-SMR...
>>>
>>
>> They  should add this API when the add the use of it then.  I don't 
>> see it in any sources.
>
> We'll see what Erik wants to do...

The new iterators should be more than enough, so that closure-based API 
is not going to be missed when removed.

>
>>
>>>
>>>> If these functions xchg_smr_thread_list, get_smr_java_thread_list, 
>>>> inc_smr_deleted_thread_count are only used by thread.cpp, I think 
>>>> they should go in that file and not in the .inline.hpp file to be 
>>>> included and possibly called by other files.  I think they're 
>>>> private to class Threads.
>>>
>>> I have a vague memory that some of the compilers don't do inlining when
>>> an "inline" function is in a .cpp. I believe we want these functions
>>> to be inlined for performance reasons. Erik should probably chime in
>>> here.
>>
>> I don't see why this should be.  Maybe some (older) compilers require 
>> it to be found before the call though, but that can still be 
>> accomplished in the .cpp file.
>
> Again, we'll see what Erik wants to do...

I don't mind. Either file works for me. For me it's more intuitive if 
inline member function definitions are in the .inline.hpp files. But if 
there are strong forces to move this to the cpp file, then sure.

Thanks,
/Erik