RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout

Dmitry Dmitriev dmitry.dmitriev at oracle.com
Wed Nov 11 08:44:26 UTC 2015


David,

You are right! I read "UINT_MAX" as "UINTX_MAX".

Thanks,
Dmitry

----- Original Message -----
From: david.holmes at oracle.com
To: dmitry.dmitriev at oracle.com
Cc: gerard.ziemski at oracle.com, hotspot-dev at openjdk.java.net
Sent: Wednesday, November 11, 2015 11:36:23 AM GMT +03:00 Iraq
Subject: Re: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout

Hi Dmitry,

On 11/11/2015 6:27 PM, Dmitry Dmitriev wrote:
> Hello David,
>
> I think that UINT_MAX upper range is not quite correct, because ErrorLogTimeout value is multiplied on 1000 and we can get overflow. Thus, more accurate is UINT_MAX / 1000.
>  From the other hand, os::sleep second argument have type 'jlong'. And very big ErrorLogTimeout values can become negative after converting to the 'jlong'. In this case I think that upper range should be something like that: 'max_jlong / 1000'

Not sure how a 32-bit UINT can overflow a 64-bit jlong? But this:

    os::sleep(this, ErrorLogTimeout * 1000, false); // in seconds

should be:

    os::sleep(this, ErrorLogTimeout * CONST_64(1000), false); // in seconds

to avoid the negative values.

Thanks,
David

> Thanks,
> Dmitry
>
>
> ----- Original Message -----
> From: david.holmes at oracle.com
> To: gerard.ziemski at oracle.com, hotspot-dev at openjdk.java.net
> Sent: Wednesday, November 11, 2015 5:44:17 AM GMT +03:00 Iraq
> Subject: Re: RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout
>
> On 11/11/2015 5:34 AM, gerard ziemski wrote:
>>
>> hi all,
>>
>> Please review this small fix for JEP-245, which implements range for the
>> last new runtime flag.
>>
>>       bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>    webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>
> This seems an artificial constraint. Why should I not be able to specify
> 0 or UINT_MAX? A range check is for validity not sensibility, and all
> values are valid here.
>
> David
>
>>
>> Thank you.
>>
>>


More information about the hotspot-dev mailing list