[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-compiler-dev
Subject:    Re: RFR 8189838: Stack overflow when computing upward projection of an intersection type with fbound
From:       Maurizio Cimadamore <maurizio.cimadamore () oracle ! com>
Date:       2017-10-26 17:49:02
Message-ID: 78f00a0e-9f3d-024f-f939-e9a81cd6589a () oracle ! com
[Download RAW message or body]

Thanks - pushed.

Maurizio


On 26/10/17 18:36, Vicente Romero wrote:
> looks good,
>
> Vicente
>
> On 10/26/2017 11:09 AM, Maurizio Cimadamore wrote:
>> Hi,
>> the patch fixes a bug in the logic for detecting fbounds loop in the 
>> LVTI upward projection logic. Basically when we recurse projection on 
>> a type-variable (upper) bound, we must keep track of the variable 
>> somewhere, as the bound can contain the variable itself, and lead to 
>> infinite loops.
>>
>> I was aware of the situation and the original code was already doing 
>> something in this regard - however, the try/finally used to 
>> add/remove the variable to the list of seen variables was too broad, 
>> and it ended up also removing type-var in case of cycles, thus 
>> defeating the purpose of the logic, at least in certain examples.
>>
>> I've rectified the logic so that now a variable is removed from the 
>> list at the end of its projection _only_ if no cycle has been 
>> detected. Also, when a cycle is indeed detected, we need to return 
>> either Object or <null> depending on the projection kind.
>>
>> Webrev here:
>>
>> http://cr.openjdk.java.net/~mcimadamore/8189838/
>>
>> Cheers
>> Maurizio
>>
>

[prev in list] [next in list] [prev in thread] [next in thread]