RFR (s) 8141570: Fix Zero interpreter build for --disable-precompiled-headers

[Coleen Phillimore]

Sorry that was the wrong webrev:

open webrev at http://cr.openjdk.java.net/~coleenp/8141570.02/
bug link https://bugs.openjdk.java.net/browse/JDK-8141570

Thanks,
Coleen

On 11/16/15 7:56 PM, Coleen Phillimore wrote:
>
> After much discussion between Kim and I, I have a new change which 
> doesn't include .inline.hpp into a .hpp file.  This also fixes the 
> Zero build on my Ubuntu system.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8140685.02/
> bug link https://bugs.openjdk.java.net/browse/JDK-8140685
>
> Thanks,
> Coleen
>
> On 11/10/15 6:00 AM, Severin Gehwolf wrote:
>> On Mon, 2015-11-09 at 17:24 -0500, Coleen Phillimore wrote:
>>>> FWIW, the below hunk seems to be all that's necessary in order to
>>>> fix
>>>> the --disable-precompiled-headers Zero build for me:
>>>>
>>>> diff --git a/src/share/vm/runtime/java.cpp
>>>> b/src/share/vm/runtime/java.cpp
>>>> --- a/src/share/vm/runtime/java.cpp
>>>> +++ b/src/share/vm/runtime/java.cpp
>>>> @@ -49,6 +49,7 @@
>>>>    #include "runtime/arguments.hpp"
>>>>    #include "runtime/biasedLocking.hpp"
>>>>    #include "runtime/compilationPolicy.hpp"
>>>> +#include "runtime/deoptimization.hpp"
>>>>    #include "runtime/fprofiler.hpp"
>>>>    #include "runtime/init.hpp"
>>>>    #include "runtime/interfaceSupport.hpp"
>>>>
>>>> It does not seem the other change is required. Tested with
>>>> fastdebug
>>>> build of Zero with --disable-precompiled-headers that failed to
>>>> build
>>>> without and built fine with the fix.
>>> I could check in just the deoptimization.hpp change and build only
>>> fastdebug until the other bug is fixed.
>> This sounds good to me.
>>
>>>> Coleen, do you have details about the failure which gets supposedly
>>>> fixed by the other hunk?
>>> The only thing I have is the g++ compilation failures without these
>>> changes.  The one that was fixed by including allocation.inline.hpp
>>> was:
>>>
>>> Building target 'images' in configuration 'linux-x86_64-normal-zero-
>>> release'
>>> g1EvacStats.o: In function `G1EvacStats::~G1EvacStats()':
>>> /home/cphillim/hg.local/jdk9.zero/hotspot/src/share/vm/gc/g1/g1EvacSt
>>> ats.hpp:32:
>>> undefined reference to `CHeapObj<(MemoryType)5>::operator
>>> delete(void*)'
>>> collect2: error: ld returned 1 exit status
>>>
>>> Since the destructor is complaining about the missing delete
>>> operator, I
>>> assume this compiler has the sort of destructor that implicitly can
>>> also
>>> call delete.  I don't have any other information or ideas really why
>>> this fails to compile.
>> Thanks!
>>
>> FWIW, I don't reproduce the g1EvacStats.o linking problem. With the
>> deoptimization.hpp change a Zero JVM builds fine here in all variants:
>> release/fastdebug/slowdebug.
>>
>> $ gcc --version
>> gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There 
>> is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
>> PURPOSE.
>>
>> Thanks,
>> Severin
>