RFR: 8199220: Zero build broken

[Edward Nevill]

On Wed, 2018-03-07 at 14:40 +0100, Erik Österlund wrote:
> 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.

Ok. Just to confirm what you are saying. For C1 (or Zero)
on_slowpath_allocation_exit should be a no-op therefore I should delete
the #else and the guarantee above and the above should just become

593 #endif

Note: For C1 (or Zero) it is not possible to assert that
ReduceInitialCardMarks is false because ReduceInitialCardMarks is not
even defined. It is defined in c2_globals.hpp and jvmci_globals.hpp

If my understanding is correct I will generate a new webrev with this
change and the change proposed by Adrian (change summary to "Zero build
broken after 8195103".

Thanks for your help reviewing this,
Ed.