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