Review request: 8003935: Simplify the needed includes for using Thread::current()
Stefan Karlsson
stefan.karlsson at oracle.com
Sun Nov 25 23:05:53 PST 2012
On 2012-11-23 13:22, David Holmes wrote:
> Hi Stefan,
>
> I never did like these.
>
> I have to wonder though, why isn't it "runtime/thread.hpp" that all
> the client code #includes?
Typically, you place inline functions in a inline.hpp file instead of
the hpp. This helps reducing the number of unnecessary includes from
spreading through out the code base. Only the users of the inline
functions will include the inline.hpp file, and bring in the needed
includes to implement the function.
Preferably, you should only include inline.hpp files from other cpp
files or other inline.hpp files.
> And then why isn't it thread.hpp that includes the platform specific
> header?
In this specific case, there's an inline function in
thread_solaris.inline.hpp that Thread::current() needs.
StefanK
>
> David
>
> On 23/11/2012 9:54 PM, Stefan Karlsson wrote:
>> http://cr.openjdk.java.net/~stefank/8003935/webrev
>>
>> Today, whenever we use Thread::current() we have to all these lines:
>>
>> #include "runtime/thread.hpp"
>> #ifdef TARGET_OS_FAMILY_linux
>> # include "thread_linux.inline.hpp"
>> #endif
>> #ifdef TARGET_OS_FAMILY_solaris
>> # include "thread_solaris.inline.hpp"
>> #endif
>> #ifdef TARGET_OS_FAMILY_windows
>> # include "thread_windows.inline.hpp"
>> #endif
>> #ifdef TARGET_OS_FAMILY_bsd
>> # include "thread_bsd.inline.hpp"
>> #endif
>>
>> This patch hides this dispatching in a new file named thread.inline.hpp.
>> Now we only have to include thread.inline.hpp.
>>
>> Some background to these includes: This type of dispatching was
>> introduced into the source files when we removed the includeDB files. We
>> discussed whether we should use "dispatch files" or not for this kind
>> platform dependent includes. The decision was to not create dispatch
>> files for all types of platform at that time, but instead manually
>> create them when we thought it was warranted.
>>
>> thanks,
>> StefanK
>>
>>
More information about the hotspot-dev
mailing list