RFR(XL): 8167108 - SMR and JavaThread Lifecycle

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed Nov 22 12:54:51 UTC 2017


On 11/22/17 4:48 AM, Erik Österlund wrote:
> 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.

I will delete it in the wrap up round.


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

I prefer inline member function definitions in the .inline.hpp files.
(There might even be a style guide note about this...)

Coleen, are you okay if we leave them there?

Dan


>
> Thanks,
> /Erik
>




More information about the hotspot-gc-dev mailing list