Re: meth-lazy bug in bytecode generation?
On May 10, 2012, at 10:33 AM, Charles Oliver Nutter wrote: > Here's a dump of one of the classes in question. Note that offset 7 in > the invoke method is definitely wrong: > https://gist.github.com/5a5e49f31bc79ac344b3 > > Christian so far can't reproduce, but it seems like a strange thing to > be a problem only in my build... I just pushed my latest changes. Let me know if it still reproduces. -- Chris > > - Charlie > > On Thu, May 10, 2012 at 11:49 AM, Charles Oliver Nutter > wrote: >> On Thu, May 10, 2012 at 1:24 AM, Michael Haupt >> wrote: >>> hard to tell what's wrong without seeing the bytecode. :-) >> >> Indeed! >> >>> Please set InvokerBytecodeGenerator.DUMP_CLASS_FILES to true to have all >>> LFI (NFI, EI) class files serialised. This also enables unique numbering. >>> The dumped class files contain textual descriptions of the respective LFs as >>> well, so it's easier to see what the problem is all about. >> >> Ok, I'll see if I can get dumps today. I did show it to Christian last >> night, so he may have something in progress to investigate...but I'm >> happy to provide dumps too. >> >> - 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
Re: meth-lazy bug in bytecode generation?
Here's a dump of one of the classes in question. Note that offset 7 in the invoke method is definitely wrong: https://gist.github.com/5a5e49f31bc79ac344b3 Christian so far can't reproduce, but it seems like a strange thing to be a problem only in my build... - Charlie On Thu, May 10, 2012 at 11:49 AM, Charles Oliver Nutter wrote: > On Thu, May 10, 2012 at 1:24 AM, Michael Haupt > wrote: >> hard to tell what's wrong without seeing the bytecode. :-) > > Indeed! > >> Please set InvokerBytecodeGenerator.DUMP_CLASS_FILES to true to have all >> LFI (NFI, EI) class files serialised. This also enables unique numbering. >> The dumped class files contain textual descriptions of the respective LFs as >> well, so it's easier to see what the problem is all about. > > Ok, I'll see if I can get dumps today. I did show it to Christian last > night, so he may have something in progress to investigate...but I'm > happy to provide dumps too. > > - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: meth-lazy bug in bytecode generation?
On Thu, May 10, 2012 at 1:24 AM, Michael Haupt wrote: > hard to tell what's wrong without seeing the bytecode. :-) Indeed! > Please set InvokerBytecodeGenerator.DUMP_CLASS_FILES to true to have all > LFI (NFI, EI) class files serialised. This also enables unique numbering. > The dumped class files contain textual descriptions of the respective LFs as > well, so it's easier to see what the problem is all about. Ok, I'll see if I can get dumps today. I did show it to Christian last night, so he may have something in progress to investigate...but I'm happy to provide dumps too. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: meth-lazy bug in bytecode generation?
Charlie, Am 10.05.2012 um 06:36 schrieb Charles Oliver Nutter: > Christian suggested -Xverify:all, which provides > the following...so I guess something is generating bad code here? > > Invalid gemspec in > [/Users/headius/projects/jruby/lib/ruby/gems/shared/specifications/trinidad_jars-1.0.3.gemspec]: > (class: java/lang/invoke/LambdaForm$LFI, method: invoke signature: > (Ljava/lang/invoke/MethodHandle;Ljava/lang/Object;Ljava/lang/Object;)V) > Expecting to find integer on stack hard to tell what's wrong without seeing the bytecode. :-) Please set InvokerBytecodeGenerator.DUMP_CLASS_FILES to true to have all LFI (NFI, EI) class files serialised. This also enables unique numbering. The dumped class files contain textual descriptions of the respective LFs as well, so it's easier to see what the problem is all about. Best, Michael -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Labs Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany Oracle is committed to developing practices and products that help protect the environment ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
meth-lazy bug in bytecode generation?
I'm getting a lot of these messages trying to test against meth-lazy, which is preventing me from validating it for larger benchmarks and JRuby's test suite: Invalid gemspec in [/Users/headius/projects/jruby/lib/ruby/gems/shared/specifications/treetop-1.4.10.gemspec]: === DEBUG MESSAGE: illegal bytecode sequence - method not verified Invalid gemspec in [/Users/headius/projects/jruby/lib/ruby/gems/shared/specifications/trinidad-1.3.5.gemspec]: === DEBUG MESSAGE: illegal bytecode sequence - method not verified Invalid gemspec in [/Users/headius/projects/jruby/lib/ruby/gems/shared/specifications/trinidad_jars-1.0.3.gemspec]: === DEBUG MESSAGE: illegal bytecode sequence - method not verified Invalid gemspec in [/Users/headius/projects/jruby/lib/ruby/gems/shared/specifications/tzinfo-0.3.33.gemspec]: === DEBUG MESSAGE: illegal bytecode sequence - method not verified I tracked this message down to TemplateInterpreterGenerator::set_entry_points in templateInterpreter.cpp. If I'm reading it right, this message is set as a default for several of the various entry points, which are *supposed* to be updated if the given bytecode is valid. If it's not, you get this result when it attempts to proceed. Now normally JRuby loads itself from boot classloader, to skip verification for code that has been verified a million times in test runs. So I thought perhaps if I forced it to verify I'd see it fail in the actual verifier. No dice, I still get these messages. If I turn off indy, the messages go away. If I run without meth-lazy, the messages go away. Christian suggested -Xverify:all, which provides the following...so I guess something is generating bad code here? Invalid gemspec in [/Users/headius/projects/jruby/lib/ruby/gems/shared/specifications/trinidad_jars-1.0.3.gemspec]: (class: java/lang/invoke/LambdaForm$LFI, method: invoke signature: (Ljava/lang/invoke/MethodHandle;Ljava/lang/Object;Ljava/lang/Object;)V) Expecting to find integer on stack - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
