RFR 8189838: Stack overflow when computing upward projection of an intersection type with fbounds
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Oct 26 17:49:02 UTC 2017
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
>>
>
More information about the compiler-dev
mailing list