An example of substituability test that is recursive

[Karen Kinnear]

Option #1 was what I was suggesting in the meeting two weeks ago - if this starts
to recurse too deeply, create a worklist - which should give you the same result.

If you switch to .Equals - you might get a different result …

thanks,
Karen

> On Jan 31, 2019, at 1:46 PM, forax at univ-mlv.fr wrote:
> 
> 
> 
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Karen Kinnear" <karen.kinnear at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Envoyé: Jeudi 31 Janvier 2019 19:05:33
> Objet: Re: An example of substituability test that is recursive
> On Jan 31, 2019, at 6:34 AM, forax at univ-mlv.fr <mailto:forax at univ-mlv.fr> wrote:
> 
> 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.
> 
> What you are doing here, I think, is exposing a requirement
> that we *don't* use the control stack for recursion on subst.
> testing (or hashing).  That's a reasonable requirement.
> It leads to a worklist algorithm for doing this tricky thing,
> just like we had to do many times in the JIT.
> 
> 
> 
> IMO that the other solution,
> solution 1: you use a worklist (and also perhaps a marking algorithm to avoid to crawle the DAG)
> solution 2: you claim it's too complex and you just let the user deal with it by calling equals() (and provide a way for a user to call the default subst).
> 
> Rémi
>