Thanks a bunch y'all. I'm thinking invokebinder should do the "right thing" and manually apply the filters in the proper order on affected JVMs...or perhaps always. Warm-up notwithstanding, what cost would we pay to always do single filter MHs versus doing them as a group that instead becomes single LF adaptations?
On Wed, Jan 3, 2018, 21:22 John Rose <john.r.r...@oracle.com> wrote: > Thanks, IBM!! > > Filed: https://bugs.openjdk.java.net/browse/JDK-8194554 > > On Jan 3, 2018, at 12:04 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > > 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.r...@oracle.com> > *À: *"Da Vinci Machine Project" <mlvm-dev@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 <head...@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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
