I have seen a stack map issue with ASM 4 as well. In my case it was dead ( unreachable ) code which had a return instruction in it. Seemed to confuse the next stack map computation. I am allowing ASM 4 to compute the maps on its own.
I replaced it (the return) with no ops and the problem went away. The other dead instructions did not seem to matter. mark From: Charles Oliver Nutter <[email protected]> To: Da Vinci Machine Project <[email protected]> Date: 04/28/2011 11:17 AM Subject: Re: Assembly output from JRuby 'fib' Sent by: [email protected] On Thu, Apr 28, 2011 at 11:03 AM, Rémi Forax <[email protected]> wrote: > On 04/28/2011 03:56 PM, Charles Oliver Nutter wrote: >> stack map is invalid. Could be an ASM bug? > > yes. it could :) > > Also it could be a bug on your side because to calculate stackmap > ASM needs to be able to find the common supertype of two types. > I don't know if you provide your own method for doing that but > by default it relies on reflection (getSupperClass/isAssignableFrom) > which doesn't work if your code use a Class that doesn't exist yet. If you're willing, I'll toss you 1.5 and 1.6 ASM-produced bytecode off-list and perhaps you can help me figure out if I'm doing something wrong or if ASM is choking on our peculiar code structure. I need this working to start running tests with invokedynamic. - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
