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
Re: Lazy Method Handle update
Thanks for the update, John! Comments below... On Wed, May 9, 2012 at 2:34 PM, John Rose wrote: > In JDK 7 FCS a method handle is represented as a chain of argument > transformation blocks, ending in a pointer to a methodOop. The argument > transformations are assembly coded and work in the interpreter stack. The > reason this is not outrageously slow is that we vigorously inline method > handle calls whenever we can. But there is a performance cliff you can drop > off of, when you are working with non-constant MHs. (BTW, invokedynamic > almost always inlines its target.) Project Lambda needs us not to drop off > of this cliff. And I need you to not drop off that cliff too! It's very easy to trigger...just make a method big enough, and RRGH into the pit you go. Luckily, for the ambitious early-access JRuby users running JRuby master + Java 7u2+ in production, the code they're hitting is all small enough to avoid the cliff, but with JRuby 1.7 preview release coming out in a couple weeks more people are going to start trying things out. > To fix this, we are now representing the argument transformations using a > simple AST-like IR, called a LambdaForm. This form can be easily rendered > down to bytecodes. (Eventually it maybe directly rendered to native code.) > The form is *also* interpretable by a Java-coded AST walker. This allows the > system to be lazy, and to work hardest on optimizing those method handles > that are actually called frequently. The laziness also helps simplify > bootstrapping. The remaining assembly code is much smaller, and can be > mirrored in the JIT IR and optimized. It also creates some *epic* stack traces when it blows up. Will those fold away in the future? > Here's an update on where we are. Christian Thalinger, Michel Haupt, and I > are currently working on the following tasks: > > A. clean out the compiled method calling path, for non-constant method handles > B. flatten the BMH layout (no boxing, linked lists, or arrays) > C. make the handling of MethodType checking visible to the compiler (removing > more assembly code) > D. tuning reuse and compilation of LambdaForm instances > E. profiling MH.LambdaForm values at MH call sites > F. tuning optimization of call sites involving LFs I have been tossing numbers and benchmarks back and forth with Christian, and now testing a local build of the meth-lazy stuff myself. Numbers haven't been great, but I think Christian made great progress today (based on an email showing C1 + indy beating C1 without indy and drastically beating C1 + indy in a stock u6 build that falls off the cliff). It's very exciting! > For A. the remaining snag is getting the argument register assignments > correct for the call to the target method. There is also an issue with > representing non-nominal calls in the backend. I assume this is the problem Christian described to me, where it was calling back into the interpreter to fix up the arguments? > For B. we are currently working on bootstrap issues. The idea here is that, > while we can do escape analysis, etc., a cleaner data structure will make the > compiler succeed more often. I will be *thrilled* when EA works across indy call sites. We have started work on our new compiler, which uses a simpler intermediate representation and which will be indy-only from day 1. Already we're seeing gains since we don't have to hand-write all the different call paths we want to represent; we can wire up any combinations of arguments, handles, and target using only method handles. That means we do things that will be ripe for EA like: * Allocating heap storage for closures right next to the closure creation * Passing closures as a handle rather than as an opaque, polymorphic structure * Specializing closure-receiving code in *our* compiler until Hotspot can specialize it for us I'd be very surprised if we can't approach Java performance for the *general* cases of Ruby code by end of year, and if we can specialize closure-receiving code *and* get EA, we might be able to compete with Java 8 lambda performance for Ruby's closures too. We also have our own profiling, inlining, and so on...but that's all above the level of bytecode to work around as-yet-unoptimized patterns in Hotspot. :) > For C. we have a refactoring in process for moving the MT value out of the > methodOop. > > Chris, Michael, and I are working on A, B, C, respectively. We think a first > cut of lazy MHs needs the first three items in order to be reasonably faster > than the all-assembly implementation of JDK 7. > > In order to address the infamous NoClassDefFound error, we are minimizing > nominal information in MH adapter code (LambdaForms and their bytecode). > Only names on the BCP will be in adapter code. Part C. is an important part > of this, since it allows the system to internally "flatten" calls like > MH.invokeExact((MyFunnyType)x) to MH.invokeExact((Object)x). The new > i
Re: Lazy Method Handle update
from John There may be a type-safe way to use them... Well since I only have one type I guess I don't have to wait -) regards mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Lazy Method Handle update
On May 9, 2012, at 1:37 PM, Mark Roos wrote: > > Quite interesting John. A few curiosity based questions. > > we are now representing the argument transformations using > a simple AST-like IR, called a LambdaForm > > would this be something we could inspect, build or manipulate? Only in privileged code. Like the sun.misc.Unsafe API, LFs and the associated non-public MH APIs are designed to be partially type-unsafe, and usable only from trusted code. There may be a type-safe way to use them beyond implementing JSR 292, but that would require further research. (Which this community enjoys!) For an approximately current sketch of lambda forms, see this file: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy.txt Especially the section "## form". A key feature of LFs is that their grammar is regular but not recursive (I can't resist: sub-Chomskian). > This form can be easily rendered down to bytecodes > > Are these jvm bytecodes or internal to hotspot? Again would this be a space > one > could play in? Vanilla JVM bytecodes. Some of the magic comes from the methods they are able to call, like MethodHandle.invokeBasic. These work (in a sense) like extended bytecodes. > thanks for the update My pleasure. — John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: selective inlining of MH.invokeExact() callsites
On May 9, 2012, at 11:15 AM, Rémi Forax wrote: > On 05/09/2012 08:02 PM, Christian Thalinger wrote: >> On May 8, 2012, at 2:11 AM, Garcia Gutierrez Miguel Alfredo wrote: >> >>> What's the behavior of @ForceInlining , in particular for >>> MethodHandle.invokeExact() ? >> We introduced that annotation as an experiment for inlining exact invokers >> for LambdaForms (note: LambdaForm is not directly related to Project >> Lambda). The generated bytecode versions of these LFs are usually just >> argument shuffling or binding and calling the target. We know that this >> code compiles down to almost nothing in native machine code and that's why >> we force them to inline. >> >> The ForceInline annotation is a powerful tool which may produce bad results >> in the hands of costumers. Currently we don't hide it completely from users >> but that might happen in the future. > > and Christian correctly if I'm wrong but it only forces inlining when > the JIT is triggered. > So using the annotation on something which is not called enough will do > nothing. Correct. > > As I said in an earlier mail, the golden hammer is the annotation > PleaseJITThisCodeWithAPrivateMetaDataObjectNowAndReJITLaterWhenTheMethodOrTheLoopIsHot > Also correct :-D -- Chris > > >> >> -- Chris > > Rémi > > ___ > 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: Lazy Method Handle update
Quite interesting John. A few curiosity based questions. we are now representing the argument transformations using a simple AST-like IR, called a LambdaForm would this be something we could inspect, build or manipulate? This form can be easily rendered down to bytecodes Are these jvm bytecodes or internal to hotspot? Again would this be a space one could play in? thanks for the update mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Lazy Method Handle update
Lazy Method Handles is a project to defer code generation for method handle behavior, and minimize requirements for support from hand-written assembly code. The idea is to make all method handle behavior visible to the JVM compiler, so that it can be optimized properly. Assembly code cannot be optimized. In JDK 7 FCS a method handle is represented as a chain of argument transformation blocks, ending in a pointer to a methodOop. The argument transformations are assembly coded and work in the interpreter stack. The reason this is not outrageously slow is that we vigorously inline method handle calls whenever we can. But there is a performance cliff you can drop off of, when you are working with non-constant MHs. (BTW, invokedynamic almost always inlines its target.) Project Lambda needs us not to drop off of this cliff. To fix this, we are now representing the argument transformations using a simple AST-like IR, called a LambdaForm. This form can be easily rendered down to bytecodes. (Eventually it maybe directly rendered to native code.) The form is *also* interpretable by a Java-coded AST walker. This allows the system to be lazy, and to work hardest on optimizing those method handles that are actually called frequently. The laziness also helps simplify bootstrapping. The remaining assembly code is much smaller, and can be mirrored in the JIT IR and optimized. Here's an update on where we are. Christian Thalinger, Michel Haupt, and I are currently working on the following tasks: A. clean out the compiled method calling path, for non-constant method handles B. flatten the BMH layout (no boxing, linked lists, or arrays) C. make the handling of MethodType checking visible to the compiler (removing more assembly code) D. tuning reuse and compilation of LambdaForm instances E. profiling MH.LambdaForm values at MH call sites F. tuning optimization of call sites involving LFs For A. the remaining snag is getting the argument register assignments correct for the call to the target method. There is also an issue with representing non-nominal calls in the backend. For B. we are currently working on bootstrap issues. The idea here is that, while we can do escape analysis, etc., a cleaner data structure will make the compiler succeed more often. For C. we have a refactoring in process for moving the MT value out of the methodOop. Chris, Michael, and I are working on A, B, C, respectively. We think a first cut of lazy MHs needs the first three items in order to be reasonably faster than the all-assembly implementation of JDK 7. In order to address the infamous NoClassDefFound error, we are minimizing nominal information in MH adapter code (LambdaForms and their bytecode). Only names on the BCP will be in adapter code. Part C. is an important part of this, since it allows the system to internally "flatten" calls like MH.invokeExact((MyFunnyType)x) to MH.invokeExact((Object)x). The new internal MH methods (invokeBasic, invokeStatic, etc.) all use "denominalized" types, which is to say that all reference types are represented as java.lang.Object. Best wishes, — John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: OSX port
On May 9, 2012, at 11:07 AM, Charles Oliver Nutter wrote: > I managed to get MLVM to build on OS X Snow Leopard with Henri's scripts. > Notes: > > * I get a failure like this at the end of the build, but this appears > to be after the jdk/jre have successfully built (or at least it > appears to work fine): https://gist.github.com/749b4fe1d3b469644c11 Yes, I get this too. I don't know where it comes from. There is probably some configuration variable that will make it go away. Like you, I saw that the build was usable and moved on. > * In order to get the meth-lazy patches to apply (I'm testing the new > indy backend) I had to remove -testable from them. I'd like a cleaner > way. Christian Thalinger, Michael Haupt, and I are working hard to get these patches ready for prime time. There are several problems that show up in comprehensive testing. The worst is that TieredCompilation mode shows some failures. Until we get cleaner tests, we're keeping "-testable". (This raises the question of whether the keyword is misleading but I can't think of another candidate meaning for "testable". Keyword means "able to pass reasonable tests", not "able to commence testing"; the latter phrase is the meaning of "buildable".) You could regard the act of removing "-testable" as the equivalent of clicking through the "yes I know what I'm doing" button. You can disable the testable filter by adjusting either the series file (which is managed source code) or the guards file (which is unmanaged and private to the installation). — John ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: selective inlining of MH.invokeExact() callsites
On 05/09/2012 08:02 PM, Christian Thalinger wrote: > On May 8, 2012, at 2:11 AM, Garcia Gutierrez Miguel Alfredo wrote: > >> What's the behavior of @ForceInlining , in particular for >> MethodHandle.invokeExact() ? > We introduced that annotation as an experiment for inlining exact invokers > for LambdaForms (note: LambdaForm is not directly related to Project > Lambda). The generated bytecode versions of these LFs are usually just > argument shuffling or binding and calling the target. We know that this code > compiles down to almost nothing in native machine code and that's why we > force them to inline. > > The ForceInline annotation is a powerful tool which may produce bad results > in the hands of costumers. Currently we don't hide it completely from users > but that might happen in the future. and Christian correctly if I'm wrong but it only forces inlining when the JIT is triggered. So using the annotation on something which is not called enough will do nothing. As I said in an earlier mail, the golden hammer is the annotation PleaseJITThisCodeWithAPrivateMetaDataObjectNowAndReJITLaterWhenTheMethodOrTheLoopIsHot > > -- Chris Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: OSX port
I managed to get MLVM to build on OS X Snow Leopard with Henri's scripts. Notes: * I get a failure like this at the end of the build, but this appears to be after the jdk/jre have successfully built (or at least it appears to work fine): https://gist.github.com/749b4fe1d3b469644c11 * In order to get the meth-lazy patches to apply (I'm testing the new indy backend) I had to remove -testable from them. I'd like a cleaner way. - Charlie On Wed, May 9, 2012 at 5:54 PM, Christian Thalinger wrote: > > On May 8, 2012, at 9:00 AM, Henri Gomez wrote: > Any date about back port/merge of OSX support in mlvm project ? >>> >>> What exactly do you think is missing? Does the build fail for you? John >>> updated the mlvm patches a couple of days ago to the recent hotspot-comp >>> repository versions which should include OS X support. >> >> Good news. >> >> We still need multiples patches process ? > > I'm not sure I understand what you mean by "multiple patches" but your build > script seems to be doing what is required. > > -- Chris > >> >> cf: >> http://openjdk-osx-build.googlecode.com/svn/trunk/build-openjdk8-64-mlvm.sh >> ___ >> 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
Re: selective inlining of MH.invokeExact() callsites
On May 8, 2012, at 2:11 AM, Garcia Gutierrez Miguel Alfredo wrote: > > What's the behavior of @ForceInlining , in particular for > MethodHandle.invokeExact() ? We introduced that annotation as an experiment for inlining exact invokers for LambdaForms (note: LambdaForm is not directly related to Project Lambda). The generated bytecode versions of these LFs are usually just argument shuffling or binding and calling the target. We know that this code compiles down to almost nothing in native machine code and that's why we force them to inline. The ForceInline annotation is a powerful tool which may produce bad results in the hands of costumers. Currently we don't hide it completely from users but that might happen in the future. -- Chris > > The context for this question is ongoing brainstorming on a new compilation > scheme for the Scala compiler: > > http://mail.openjdk.java.net/pipermail/graal-dev/2012-May/38.html > http://mail.openjdk.java.net/pipermail/graal-dev/2012-May/40.html > > https://groups.google.com/d/topic/jvm-languages/eEp3Z8tS8wo/discussion > > > Miguel > http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/ > ___ > 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: OSX port
On May 8, 2012, at 9:00 AM, Henri Gomez wrote: >>> Any date about back port/merge of OSX support in mlvm project ? >> >> What exactly do you think is missing? Does the build fail for you? John >> updated the mlvm patches a couple of days ago to the recent hotspot-comp >> repository versions which should include OS X support. > > Good news. > > We still need multiples patches process ? I'm not sure I understand what you mean by "multiple patches" but your build script seems to be doing what is required. -- Chris > > cf: > http://openjdk-osx-build.googlecode.com/svn/trunk/build-openjdk8-64-mlvm.sh > ___ > 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
