----- Mail original -----
> De: "Karen Kinnear" <karen.kinn...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net>
> Envoyé: Jeudi 31 Janvier 2019 14:57:32
> Objet: Re: An example of substituability test that is recursive
> Remi,
>
> Thank you. So there were two kinds of “recurse to its death” we talked about
> 1) expected behavior
> 2) surprise
>
> This strikes me as the expected behavior - where we can set expectations.
I disagree that it's the expected behavior, or it's like saying that a GC can
crash because a linked list too long is the expected behavior.
The expected behavior is to cut the recursive calls if it's too deep and
restart once you have pop all the frames.
The other solution is to say that == should do an upcall to equals (after the
null checking and the class checking), if equals throw a StackOverflow, it's
the expected behavior because the user is in control of that behavior.
>
> If we were to always return false - how would you make this kind of example
> work?
no
>
> thanks,
> Karen
Rémi
>
>> On Jan 31, 2019, at 6:19 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
>>
>> Hi Karen,
>> here is an example that recurse to its death with the current prototype
>>
>> import java.lang.invoke.ValueBootstrapMethods;
>> import java.util.stream.IntStream;
>>
>> public class Substituable {
>> static value class Link {
>> private final int value;
>> private final Object next;
>>
>> public Link(int value, Object next) {
>> this.value = value;
>> this.next = next;
>> }
>>
>> static Object times(int count) {
>> return IntStream.range(0, count).boxed().reduce(null, (acc, index) ->
>> new
>> Link(index, acc), (l1, l2) -> { throw null; });
>> }
>> }
>>
>>
>> public static void main(String[] args) {
>> var l = Link.times(1_000);
>>
>> //System.out.println(l == l);
>> System.out.println(ValueBootstrapMethods.isSubstitutable(l, l));
>> }
>> }
>>
>>
>> Rémi
