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

[Coleen Phillimore]

I also removed this line from zeroshark.make since this file has been 
gone for a long time.

OPT_CFLAGS/compactingPermGenGen.o = -O1

Thanks,
Coleen

On 11/18/15 9:03 AM, Erik Joelsson wrote:
> Hello,
>
> Build changes look ok, but I would recommend filing a followup bug for 
> fixing the warnings that are being disabled so there is something 
> tracking these issues in the zero source code.
>
> /Erik
>
> On 2015-11-17 02:36, Coleen Phillimore wrote:
>>
>> 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
>>>
>>
>