RFR: 8199220: Zero build broken

David Holmes david.holmes at oracle.com
Wed Mar 7 13:25:52 UTC 2018


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.

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
> 


More information about the hotspot-dev mailing list