RFR: 8199220: Zero build broken (original) (raw)

Erik Österlund erik.osterlund at oracle.com
Wed Mar 7 13:40:39 UTC 2018

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::onslowpathallocationexit(JavaThread* thread, oop newobj) { if (!ReduceInitialCardMarks) { return; } A second build error is /home/ed/openjdk/jdk/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:1748: undefined reference to `typeArrayOopDesc::byteatput(int, signed char)' This is caused by bytecodeInterpreter.cpp not including typeArrayOop.inline.hpp

More information about the hotspot-dev mailing list