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

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed Nov 29 22:11:55 UTC 2017


On 11/29/17 5:04 PM, coleen.phillimore at oracle.com wrote:
>
> http://cr.openjdk.java.net/~dcubed/8191787-webrev/jdk10-0/src/hotspot/share/runtime/thread.hpp.udiff.html 
>
>
> Can you put a section with the static data member declarations, then a 
> blank line and then have a section with the functions?   We don't 
> usually mix them like that (maybe in thread.hpp because it's the 
> kitchen sink but not everywhere else).  It makes it hard to read.

We're trying to keep all the "stuff" associated with a field together.
It's definitely not a style typically in use in HotSpot, but we're
experimenting with it because thread.hpp is currently a kitchen sink
collection. Some folks would say it is a mess... :-)

I'm going to take a look this cleanup bug also:

JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> 
threadSMR.[ch]pp
https://bugs.openjdk.java.net/browse/JDK-8191789

since it will primarily be "code motion" fix also. Keeping "stuff"
together will make that cleanup bug easier...

Would you be okay with this fix (8191787) as it is?


> Otherwise, looks fine.  Thank you for moving these!

Thanks!

Dan


>
> Coleen
>
> On 11/29/17 4:16 PM, 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
>>
>> 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
>



More information about the hotspot-runtime-dev mailing list