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-compiler-dev
mailing list