RFR(XL): 8167108 - SMR and JavaThread Lifecycle
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed Nov 22 13:10:34 UTC 2017
On 11/22/17 8:02 AM, coleen.phillimore at oracle.com wrote:
>
>
> On 11/22/17 7:54 AM, Daniel D. Daugherty wrote:
>> 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.
>>
>>
>
> Thank you.
>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> 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?
>
> Yes, that's fine.
Thanks for confirmation!
Dan
>
> Coleen
>
>>
>> Dan
>>
>>
>>>
>>> Thanks,
>>> /Erik
>>>
>>
>
More information about the hotspot-gc-dev
mailing list