RFR 8218031: Zero build broken
Aleksey Shipilev
shade at redhat.com
Wed Jan 30 17:18:15 UTC 2019
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/
(also note the Contributed-by line)
This passes Linux x86_64 {zero, server} builds.
-Aleksey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20190130/d49ed20c/signature.asc>
More information about the hotspot-compiler-dev
mailing list