RFR: 8199220: Zero build broken

[Erik Österlund]

Hi,

On 2018-03-07 14:25, David Holmes wrote:
> Hi Ed,
>
> On 7/03/2018 9:40 PM, Edward Nevill wrote:
>> Hi,
>>
>> Please review the following webrev which fixes broken zero build.
>>
>> Bugid: https://bugs.openjdk.java.net/browse/JDK-8199220
>> Webrev: http://cr.openjdk.java.net/~enevill/8199220/webrev.00
>>
>> As this involves changes to shared hotspot code I will need a sponsor.
>
> I'm concerned by the original code as highlighted by part of your fix:
>
>  593 #else
>  594   guarantee(false, "How did we get here?");
>  595 #endif
>
> I think Erik and/or other GC folk need to weigh in here and clearly 
> state this is intended to be a no-op unless using C2 or JVMCI. But 
> even so unless a C1 only build is completely dead, we don't want that 
> guarantee I think.

I can confirm that unless C2 or JVMCI is used, this is a no-op and 
ReduceInitialCardMarks should be false. If it is not false, there is a bug.

Thanks,
/Erik

>
> Thanks,
> David
>
>> Thanks for your help,
>> Eed.
>>
>> -----------------------------------------------------------------
>> The following symbol is reported as undefined in the Zero build
>>
>> ReduceInitialCardMarks
>>
>> This is a C2/JVMCI only symbol but is referenced unconditionally in
>>
>> src/hotspot/share/gc/shared/cardTableModRefBS.cpp
>>
>> void CardTableModRefBS::on_slowpath_allocation_exit(JavaThread* 
>> thread, oop new_obj) {
>>     if (!ReduceInitialCardMarks) {
>>       return;
>>     }
>>
>> A second build error is
>>
>> /home/ed/openjdk/jdk/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:1748: 
>> undefined reference to `typeArrayOopDesc::byte_at_put(int, signed char)'
>>
>> This is caused by bytecodeInterpreter.cpp not including 
>> typeArrayOop.inline.hpp
>>