On Jul 27, 2011, at 2:50 AM, Charles Oliver Nutter wrote:
> I'm getting back into invokedynamic stuff (in between
> conferencing...whew!). Perf reports are coming soon, but in the
> interim....
>
> I was playing with implementing "loops" using the trick Ola showed me
> of binding a call site in the chain and having it circle back to the
> top. Fun, cute, etc.
>
> https://gist.github.com/1109021
>
> (might be interesting for cookbook?)
>
> However I realized while implementing it that it kinda blurs the lines
> between recursive and iterative. Logically, the rebound call site
> should act like a backward branch to another iteration. That's what
should is a little strong. The current implementation of selectAlternative
operates in a frameless way but the old implementation did not so this is very
clearly recursion when run against that implementation. Running your example
against b143 gives this:
Exception in thread "main" java.lang.StackOverflowError
at java.lang.Long.valueOf(Long.java:573)
at sun.invoke.util.ValueConversions.boxLong(ValueConversions.java:248)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
at
java.lang.invoke.MethodHandleImpl$GuardWithTest.invoke_L2(MethodHandleImpl.java:929)
....
Presumably that's a valid implementation of selectAlternative which seems to
disallow these kinds of shenanigans at least until Java requires tail call
elimination.
Running against b147 also gives StackOverflowError, at least sometimes, but
it's more mysterious:
/java/re/jdk/1.7.0/promoted/all/b147/binaries/solaris-amd64/fastdebug/bin/java
-server -XX:+PrintCompilation -Xint IndyLoop
Exception in thread "main" java.lang.StackOverflowError
at IndyLoop.add(IndyLoop.java:64)
at IndyLoop.main(IndyLoop.java:13)
In this case I believe that we're running out space in the frame because of how
we are doing the argument swizzling for MH chains. We often do expansion
without cleaning up since we assume the amount of expansion is bounded. Making
a loop greatly extends the amount of expansion. I believe the crashes are
caused by this happening in I2C adapter code which isn't prepared to deal with
the overflow. In general it appears that the adapter code needs some stack
overflow checking. It may also need fixes to keep from over expanding the
argument area. That might allow this to run to completion in interpreted mode
but compiles are a different story.
> I'd expect to happen if everything compiles and inlines together; the
> MH chain would see that the call site is bound to an
> already-encountered handle higher up in the chain and treat it as a
> branching operation.
The compile could conceivably do something like this but it certainly doesn't
right now. It also seems pretty far outside the design center of 292 to make
it behave like this, or at least the spec should give some guidance on whether
method handle cycles are required to behave as you describe. Anyway, John
would probably have the last word here. I'm really just talking about what
happens as opposed to what should happen.
Also note that this loop will never get compiled in a normal fashion since
there are no invocation counters on method handles.
I filed 7071915 for this since we shouldn't simply crash, though a
StackOverflowError seems permissible to me.
tom
>
> It does seem to work fine for low values, but for high values I got a
> crash (on openjdk-osx-build probably equivalent to b146 or *maybe*
> b147): "Illegal instruction"
>
> Here's the full session. What sayeth ye all?
>
> https://gist.github.com/1109026
>
> I've pushed the code here:
>
> https://github.com/headius/indy-examples
>
> - Charlie
> _______________________________________________
> 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
