Writing a compiler to handles, but filter seems to executed in reverse

[Remi Forax]

IBM implementation uses the left to right order ! 
I've just tested with the latest Java 8 available. 

Java(TM) SE Runtime Environment (build 8.0.5.7 - pxa6480sr5fp7-20171216_01(SR5 FP7)) 
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20171215_373586 (JIT enabled, AOT enabled) 
OpenJ9 - 5aa401f 
OMR - 101e793 
IBM - b4a79bf) 

so it's an implementation bug, #2 seems to be the right solution. 

Rémi 

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
> Envoyé: Mercredi 3 Janvier 2018 20:37:42
> Objet: Re: Writing a compiler to handles, but filter seems to executed in
> reverse

> On Jan 2, 2018, at 12:35 PM, Charles Oliver Nutter < [
> mailto:headius at headius.com | headius at headius.com ] > wrote:

>> Is there a good justification for doing it this way, rather than having

>> filterArguments start with the *last* filter nearest the target?

> No, it's a bug. The javadoc API spec. does not emphasize the ordering
> of the filter invocations, but the pseudocode makes it pretty clear what
> order things should come in. Certainly the spec. does not promise the
> current behavior. When I wrote the spec. I intended the Java argument
> evaluation order to apply, and the filters to be executed left-to-right.
> And then, when I wrote the code, I used an accumulative algorithm
> with a for-each loop, leading indirectly to reverse evaluation order.
> Oops.

> There are two ways forward:

> 1. Declare the spec. ambiguous, and document the current behavior
> as the de facto standard.

> 2. Declare the spec. unambiguous, change the behavior to left-to-right
> as a bug fix, and clarify the spec.

> I think we can try for #2, on the grounds that multiple filters are a rare
> occurrence. The risk is that existing code that uses multiple filters *and*
> has side effect ordering constraints between the filters will break.

> Question: What does the IBM JVM do? I think they have a very
> different implementation, and they are supposed to follow the spec.

> — John

> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20180103/0b65290b/attachment.html>