RFR: 8199220: Zero build broken
edward.nevill at gmail.com
Wed Mar 7 15:26:55 UTC 2018
On Wed, 2018-03-07 at 14:40 +0100, Erik Österlund wrote:
> 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
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,
More information about the hotspot-dev