RFR 8178150: Regression in logic for handling inference stuck constraints

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Jun 13 16:01:25 UTC 2018


Here's a finalized webrev; I've incorporated few comments from this 
discussion:

* have predictable inference var resolution (B. Blaser)
* change stream back to for each (A. Golovnin)

Webrev:

http://cr.openjdk.java.net/~mcimadamore/8178150_v3/

Cheers
Maurizio



On 13/06/18 13:43, Vicente Romero wrote:
>
>
> On 06/13/2018 04:05 AM, Maurizio Cimadamore wrote:
>>
>> Resurrecting this old thread.
>>
>> There haven't been many comments on the spec side of this.
>>
>> I'm tempted to go ahead and submit (after proper re-testing) one last 
>> iteration of this patch. The focus would be on fixing the regression 
>> in stuck constraint resolution that has been affecting the compiler 
>> for a while - I plan to leave performance and spec-related issues as 
>> part of follow up tasks - I don't think we came across on evidence 
>> that this patch regresses on either fronts.
>>
>> Thoughts?
>>
>
> go for it :)
>
>> Maurizio
>>
>
> Vicente
>
>>
>> On 25/10/17 01:33, Maurizio Cimadamore wrote:
>>>
>>>
>>>
>>> On 25/10/17 00:43, Maurizio Cimadamore wrote:
>>>> lead to the same set of input variables; there is actually a very 
>>>> tiny difference, in that the latter constraint doesn't add in the 
>>>> input variable set the input variables of the constraints coming 
>>>> from the return expressions of the lambda - and that's because, I 
>>>> think, you can reason about exceptions being thrown by a lambda 
>>>> even if some return expressions are 'stuck'. Which means I guess, 
>>>> at least hypothetically, you could write a test where the spec 
>>>> picks ‹/LambdaExpression/ →_/throws/ T› and decides to process that 
>>>> ahead of  ‹/LambdaExpression/ → T› - while in javac the two happen 
>>>> at the same time (because javac doesn't have the distinction 
>>>> between these two constraints - throws constraints are evaluated as 
>>>> part of evaluating the lambda compatibility constraint).
>>> Actually, it's slightly different - that is:
>>>
>>> ‹/LambdaExpression/ →_/throws/ T›
>>>
>>> has a _broader_ set of input variables than
>>>
>>>  ‹/LambdaExpression/ → T›
>>>
>>> As the former includes as input variables all variables mentioned in 
>>> the return type of the function type derived from T.
>>>
>>> This reduces the mismatch even further - basically what the spec is 
>>> saying is that you don't want to process checked exception 
>>> constraints in cases where the target contains free variables, 
>>> because such variables might affect the set of thrown types by the 
>>> lambda.
>>>
>>> That said, I will have to think more about specific cases where the 
>>> spec would consider ‹/LambdaExpression/ →_// T› ahead of the 
>>> companion constraint ‹/LambdaExpression/ →_// throws T›, and see 
>>> what's the impact in terms of real code. From the looks of it this 
>>> looks like (i) something that was there even before the regression 
>>> that this patch is attempting to fix and (ii) probably more in the 
>>> corner case territory; while non conformance issues should be 
>>> treated for what they are, I think there's enough of a case here to 
>>> investigate this as part of a followup issue?
>>>
>>> Maurizio
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180613/79f59da6/attachment-0001.html>


More information about the compiler-dev mailing list