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