RFR(XS) 8011415: CTW on Sparc: assert(lrg.lo_degree()) failed:

[Niclas Adlertz]

I couldn't find any place where it expects a 16bit value only.

Here's an updated webrev:http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev01/

Kind Regards,
Niclas Adlertz

On 2013-10-10 09:08, Niclas Adlertz wrote:
> Hi Vladimir, thank you.
>
>> Can you use 0xFFFFF format?
> Sure, I can switch to hexadecimal format in the code. The new value already is 0xFFFFF (but in decimal representation).
>
>> It will *8 but it should be fine since we need a big number.
> Won't it be * 16? I meant it will be * 16, not doubled. Sorry for the confusion.
>
>> I am little worry that it (mask_size()) is used somewhere in a code which expects 16bit value only. Could you look?
> I will look for uses of mask_size() to see if I can find uses where it needs 16bit.
>
> I will send out an updated webrev soon.
>
> Thanks.
>
> Kind Regards,
> Niclas Adlertz
>
> On 2013-10-10 03:29, Vladimir Kozlov wrote:
>> Can you use 0xFFFFF format? It will *8 but it should be fine since we need a big number.
>> I am little worry that it (mask_size()) is used somewhere in a code which expects 16bit value only. Could you look?
>>
>> Note for reviewers:
>>
>> lo_degree() { return degree() <= degrees_of_freedom(); }
>> degrees_of_freedom() { return mask_size() - _num_regs; }
>> degree() { return _eff_degree; }
>>    uint _eff_degree; // Effective degree: Sum of neighbors _num_regs
>>
>> Thanks,
>> Vladimir
>>
>> On 10/9/13 3:08 PM, Niclas Adlertz wrote:
>>> Hi all,
>>>
>>> When compiling very big methods, in this particular case a method of
>>> 60k+ nodes, a live range 'l' with mask.is_AllStack() == true can still
>>> have lo_degree() == false. This because the _mask_size of 'l' can be at
>>> most 65535, at the same time 'l' is interfering with so many other live
>>> ranges that the value of _eff_degree becomes bigger than 65535.
>>>
>>> To solve this I've doubled that max value of _mask_size.
>>> Appreciate feedback on this. Should we increase it by more? Or find
>>> another solution for this? Or file a future enhancement bug to solve
>>> this in a cleaner way later on?
>>>
>>> (I've ran CTW + JPRT tests)
>>>
>>> WEBREV: http://cr.openjdk.java.net/~adlertz/JDK-8011415/webrev00/
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8011415
>>>
>>> Kind Regards,
>>> Niclas Adlertz
>