RFR(XS): 8191787 - move private inline functions from thread.inline.hpp -> thread.cpp

[Daniel D. Daugherty]

On 11/30/17 12:07 AM, David Holmes wrote:
> Hi Dan,
>
> On 30/11/2017 7:16 AM, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Coleen, this is one of your Thread-SMR follow-up suggestions so I need
>> to hear from you on this thread. Thanks!
>>
>> I have a simple cleanup fix for Thread-SMR. The bug is:
>>
>>      JDK-8191787 move private inline functions from thread.inline.hpp 
>> -> thread.cpp
>>      https://bugs.openjdk.java.net/browse/JDK-8191787
>>
>> This fix is pure code motion:
>>
>> - moving inline functions from thread.inline.hpp -> thread.cpp
>> - making a few functions in thread.hpp private instead of public
>>
>> Here is the webrev URL:
>>
>> http://cr.openjdk.java.net/~dcubed/8191787-webrev/jdk10-0
>
> 3779 inline ThreadsList* Threads::get_smr_java_thread_list() {
> 3780   return 
> (ThreadsList*)OrderAccess::load_acquire(&_smr_java_thread_list);
> 3781 }
>
> Don't these inline definitions need to come before any use of them 
> elsewhere in the source file, to actually get the inlining benefit?

I don't know. I was under the impression that some of the compilers
do not properly do inlining of functions in .cpp files, but I was
told during the 8167108 review that that is no longer the case with
the current compilers.

Hopefully one of the C++ compiler cognizant folks will chime in...


> Otherwise no comments from me on the code motion. I'm abstaining from 
> the debate on whether to list the functions immediately after the 
> associated fields, or whether to group fields and functions separately 
> (normally different access means they are separate, but not in this 
> case). :)

Thanks for the review!

Dan


>
> Thanks,
> David
> -----
>
>>
>> This fix was (over) tested with a Mach5 tier[1-5] run. There were no
>> unexpected test failures.
>>
>> Thanks, in advance, for any comments, questions or suggestions.
>>
>> Dan