RFR(s): 8218041: Assorted wrong/missing includes
Robbin Ehn
robbin.ehn at oracle.com
Wed Jan 30 11:06:56 UTC 2019
Hi David,
On 2019-01-30 11:52, David Holmes wrote:
>
> So if it compiles but there's no include of the .inline.hpp file that just means
> it won't get inlined - right? (ie the .hpp file must still be getting included)
If the method is inlined everywhere, there will be no symbol at link time.
Since we do not generate any object file from the inline.hpp at least one object
file from a cpp file must generate a out-line version.
Since gcc seems to have issue with inlining, we find symbol at link time.
Using clang or forcing inline via attribute linker fails if not the inline
method is included either directly or via some other include.
So you must include the inline.hpp in your cpp if you use a method from there
since no-one else is guaranteed to generate that symbol.
In this case clang manage to inline all the HandleMark().
I have now fixed all includes regarding handles.inline.hpp in cpp/inline.hpp
files, sending out a v02 in a few minutes.
Thanks, Robbin
>
> David
>
>> Compile testing this with all sort of compilers and options, now clang works.
>>
>> But the inline constructor just calls a non-inlined method:
>> inline HandleMark::HandleMark() {
>> initialize(Thread::current());
>> }
>>
>> At least now Thread::current() is in thread.hpp, so the reason for inline seem
>> not true anymore. I'm thinking that maybe I should change it and just include
>> handles.hpp on the missing places. But since HandleMarkCleaner needs the
>> inline file it's very asymmetric with HandleMark is fine with hpp but if you
>> also use HandleMarkCleaner you need the inline. So maybe I'll just leave the
>> 'dummy' inline constructor.
>>
>> So sending out an v2 of some sort.
>>
>> /Robbin
>>
>> On 2019-01-30 09:50, Kim Barrett wrote:
>>>> On Jan 30, 2019, at 3:21 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>>>
>>>> Hi all, please review.
>>>>
>>>> Code:
>>>> http://cr.openjdk.java.net/~rehn/8218041/webrev/
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8218041
>>>
>>> Looks good.
>>>
More information about the hotspot-dev
mailing list