Writing a compiler to handles, but filter seems to executed in reverse
forax at univ-mlv.fr
Wed Jan 3 20:04:40 UTC 2018
IBM implementation uses the left to right order !
I've just tested with the latest Java 8 available.
Java(TM) SE Runtime Environment (build 126.96.36.199 - 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.
> 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
> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev