review(XS): 6988308: assert((cnt > 0.0f) && (prob > 0.0f)) failed: Bad frequency assignment in if

[Igor Veresov]

On 4/13/11 12:52 AM, Christian Thalinger wrote:
> On Apr 13, 2011, at 6:37 AM, Igor Veresov wrote:
>> The problem can occur in Parse::dynamic_branch_prediction(), where cnt can become negative if the block count is larger than max int. This is because the "sum" variable is an int and Block::count() returns uint, which if large enough will make "sum" become negative, causing in turn "cnt" to become negative.
>>
>> I treated this problem by making the "sum" a float. Also, added guards to detect overflows of "taken" and "not_taken", protecting therefore against overflowing an int twice when they are added together.
>>
>> Webrev: http://cr.openjdk.java.net/~iveresov/6988308/webrev.00/
>
> The change looks good and I have a question:  how often does the overflow of taken and not_taken counts happen?

With interpreter-only profiling it will actually stop at -1, because it 
adds one and then subtracts the carry thus keeping it from turning over. 
With tiered I yet have to take care of this issue, I'm afraid - 
currently it will overflow.

But it is quite an infrequent situation. Typically it would happen if 
the code cache is full and we stop compiling and a method is stuck in 
C1+profiling state or is profiled in the interpreter.

igor


>
> -- Christian