Not me, but the Smalltalk compiler I inherited seems to see this as an easy way to convert block sends into inline code for some cases. My fix is ugly ( post process to look for dead code and remove it) so when I get around to it I plan to rewrite the compiler. But then it works so its at the bottom of the list.
Without ASM I would not have seen this bug in the compiler so thanks mark From: Rémi Forax <fo...@univ-mlv.fr> To: mlvm-dev@openjdk.java.net Date: 05/01/2011 08:44 AM Subject: Re: Assembly output from JRuby 'fib' Sent by: mlvm-dev-boun...@openjdk.java.net It's astonishing how many people want to generate dead code :) Rémi On 04/30/2011 01:03 AM, Charles Nutter wrote: Rémi and I confirmed that it is in fact dead code (JRuby's fault) which is causing a problem for ASM 4 (ASM's fault). He's looking into a fix, and I'll try to eliminate the dead code. Hopefully it can be fixed in ASM soon, since the code in question is being generated by a particularly gnarly part of JRuby's compiler. - Charlie (mobile) On Apr 29, 2011, at 15:58, Mark Roos <mr...@roos.com> wrote: 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 <head...@headius.com> To: Da Vinci Machine Project <mlvm-dev@openjdk.java.net> Date: 04/28/2011 11:17 AM Subject: Re: Assembly output from JRuby 'fib' Sent by: mlvm-dev-boun...@openjdk.java.net On Thu, Apr 28, 2011 at 11:03 AM, Rémi Forax <fo...@univ-mlv.fr> 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 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
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
