Assembly output from JRuby 'fib'

[Mark Roos]

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 <forax at univ-mlv.fr>
To:
mlvm-dev at openjdk.java.net
Date:
05/01/2011 08:44 AM
Subject:
Re: Assembly output from JRuby 'fib'
Sent by:
mlvm-dev-bounces at 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 <mroos at 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 <headius at headius.com> 
To: 
Da Vinci Machine Project <mlvm-dev at openjdk.java.net> 
Date: 
04/28/2011 11:17 AM 
Subject: 
Re: Assembly output from JRuby 'fib' 
Sent by: 
mlvm-dev-bounces at openjdk.java.net




On Thu, Apr 28, 2011 at 11:03 AM, Rémi Forax <forax at 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 at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110501/6c0b1cc8/attachment.html