RFR 8218031: Zero build broken

Ao Qi aoqi at loongson.cn
Wed Jan 30 17:32:45 UTC 2019


On Thu, Jan 31, 2019 at 1:18 AM Aleksey Shipilev <shade at redhat.com> wrote:
>
> On 1/30/19 5:44 PM, Aleksey Shipilev wrote:
> > On 1/30/19 5:38 PM, Ao Qi wrote:
> >> On Thu, Jan 31, 2019 at 12:26 AM Aleksey Shipilev <shade at redhat.com> wrote:
> >>>
> >>> On 1/30/19 5:17 PM, Ao Qi wrote:
> >>>> Webrev: http://cr.openjdk.java.net/~aoqi/8218031/webrev.00
> >>>
> >>> This looks good to me.
> >
> >
> > Let me ask a question, though, don't we want these asserts back too?
> >
> >   assert(0 <= InterpreterBackwardBranchLimit,
> >          "OSR threshold should be non-negative");
> >   assert(0 <= InterpreterProfileLimit &&
> >          InterpreterProfileLimit <= InterpreterInvocationLimit,
> >          "profile threshold should be less than the compilation threshold "
> >          "and non-negative");
> >
> > Also, why these are removed? Do they mess with buildability?
> >
> >  102   bool reached_BackwardBranchLimit(InvocationCounter *back_edge_count) const {
> >  103     return (_counter & count_mask) + (back_edge_count->_counter & count_mask) >=
> >  104            (unsigned int) InterpreterBackwardBranchLimit;
> >  105   }
> >  106   // Do this just like asm interpreter does for max speed.
> >  107   bool reached_ProfileLimit(InvocationCounter *back_edge_count) const {
> >  108     return (_counter & count_mask) + (back_edge_count->_counter & count_mask) >=
> >  109            (unsigned int) InterpreterProfileLimit;
> >
> >
> > I see that InterpreterProfileLimit is gone, but InterpreterBackwardBranchLimit is still there,
> > should we keep the assert and reached_BackwardBranchLimit then?
>
> I am thinking this:
>   http://cr.openjdk.java.net/~shade/8218031/webrev.01/
>

I am ok with this.

> (also note the Contributed-by line)
>
> This passes Linux x86_64 {zero, server} builds.
>
> -Aleksey
>
>
>


More information about the hotspot-compiler-dev mailing list