JDK-8191787 : move private inline functions from thread.inline.hpp -> thread.cpp
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2017-11-22
  • Updated: 2017-12-15
  • Resolved: 2017-12-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10 JDK 11
10 b36Fixed 11Resolved
Related Reports
Relates :  
JDK-8167108 - inconsistent handling of SR_lock can lead to crashes
Description
A comment from Coleen's code review of JDK-8167108:

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

Stefan K would also like this move made as a Thread-SMR cleanup.
Comments
These are the things to move from thread.inline.hpp -> thread.cpp: Threads::get_smr_java_thread_list() Threads::xchg_smr_java_thread_list() Threads::inc_smr_deleted_thread_cnt() Threads::update_smr_deleted_thread_time_max() Threads::add_smr_deleted_thread_times() Also looks like a few functions in thread.hpp can be made private: Threads::smr_delete_lock() Threads::smr_delete_notify() Threads::set_smr_delete_notify() Threads::clear_smr_delete_notify() Threads::inc_smr_deleted_thread_cnt() Threads::update_smr_deleted_thread_time_max() Threads::add_smr_deleted_thread_times() Threads::acquire_stable_list_fast_path() Threads::acquire_stable_list_nested_path() Threads::release_stable_list_fast_path() Threads::release_stable_list_nested_path() Threads::release_stable_list_wake_up() Of course, with code motion changes, the proof is in the building...
28-11-2017