RFR: 8199220: Zero build broken after 8195103 and 8191102 (was RFR: 8199220: Zero build broken)

[coleen.phillimore at oracle.com]

http://cr.openjdk.java.net/~enevill/8199220/webrev.02/src/hotspot/share/gc/shared/cardTableModRefBS.cpp.udiff.html

Can you add a comment on the #endif // COMPILER2 || JVMCI

something like that?
thanks,
Coleen

On 3/8/18 12:24 PM, Edward Nevill wrote:
> Hi,
>
> BugID: https://bugs.openjdk.java.net/browse/JDK-8199220
> Webrev: http://cr.openjdk.java.net/~enevill/8199220/webrev.02
>
> I have updated the webrev to include the following changes
>
> - Changed the description in the hg log to
>
> 8199220: Zero build broken after 8195103 and 8191102
>
> - Remove the guarantee in on_slowpath_allocation_exit
>
> +#else
> +  guarantee(false, "How did we get here?");
> +#endif
>
> This means on_slowpath_allocation_exit becomes a no op in C1/Zero
>
> I also rebased the webrev on jdk/hs rathat than jdk/jdk as this is a hotspot patch.
>
> While doing so I discovered more brokenness in jdk/hs caused by
>
> 8191102: Incorrect include file use in classLoader.hpp
> Summary: Move appropriate methods to <fiile>.inline.hpp files. Create <file>.inline.hpp files when needed.
>
> This moved methods to <file>.inline.hpp files but failed to update the zero specific files.
>
> I have updated this webrev with the approriate includes.
>
> Could I have a sponsor for this please,
>
> Thanks,
> Ed.
>