From howard.lovatt at gmail.com Thu Sep 2 16:29:42 2010 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Fri, 3 Sep 2010 09:29:42 +1000 Subject: Regression? Message-ID: I posted the following observation about different versions of the MLVM on Lambda Dev and at the suggestion of R?mi Forax I am reposting here. The following code: class Test { public static void print(ActionEvent e) { System.out.println("Hello!"); } public static void main(String[] args) { final ActionListener al4 = Test#print( ActionEvent ); JButton b = new JButton(); b.addActionListener(al4); b.doClick(); b.removeActionListener(al4); } } Works with the MLVM java-1.7.0-internal-2010_07_30.tar.gz from: http://www.concord.org/~sbannasch/mlvm/ Which has version number: wizziewol-ln:lambdas lov080$ jdk=/System/Library/Frameworks/JavaVM.framework/Versions/1.7.0_2010_07_30/Home/bin wizziewol-ln:lambdas lov080$ $jdk/java -version openjdk version "1.7.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.7.0-internal-fastdebug-stephen_2010_07_30_11_56-b00) OpenJDK Server VM (build 19.0-b03-fastdebug, mixed mode) But with the later build, java-1.7.0-internal-mlvm-2010_08_18.tar.gz, which has version number: wizziewol-ln:lambdas lov080$ jdk=/System/Library/Frameworks/JavaVM.framework/Versions/1.7.0_2010_08_18/Home/bin wizziewol-ln:lambdas lov080$ $jdk/java -version openjdk version "1.7.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.7.0-internal-fastdebug-stephen_2010_08_18_15_10-b00) OpenJDK 64-Bit Server VM (build 19.0-b03-fastdebug, mixed mode) It fails with: Exception in thread "main" java.dyn.WrongMethodTypeException: (Ljava/dyn/MethodHandle;Ljava/awt/event/ActionEvent;)V cannot be called as (Ljava/dyn/MethodHandle;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; at sun.dyn.FromGeneric$A2.invoke_I2(FromGeneric.java:533) at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:332) at com.sun.runtime.ProxyHelper$1.invoke(ProxyHelper.java:61) at $Proxy0.actionPerformed(Unknown Source) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2015) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2338) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.AbstractButton.doClick(AbstractButton.java:376) at javax.swing.AbstractButton.doClick(AbstractButton.java:356) at lambdas.Test.main(Test.java:18) The compile/run script is: #!/bin/sh # Compile and run Test example jdk=/System/Library/Frameworks/JavaVM.framework/Versions/1.7.0_2010_08_18/Home/bin javac=/Users/lov080/Dropbox/Personal/Java/JDK7/langtools/dist/lib/javac.jar package=lambdas name=Test cd .. rm ../build/classes/$package/$name.class # Compile (javac) $jdk/java -Xbootclasspath/p:$javac -ea -jar $javac \ -g -deprecation -source 7 -Xlint:all -XDallowFunctionTypes -d ../build/classes \ $package/$name.java cd ../build/classes # Run $jdk/java -cp .:$javac -ea -Xfuture \ -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic \ -XX:SuppressErrorAt=/constantPoolOop.cpp:283 \ $package.$name Where javac.jar is made from the JDK 7 mercurial repository. Cheers, ? -- Howard. From john.r.rose at oracle.com Sun Sep 5 00:23:50 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 5 Sep 2010 00:23:50 -0700 Subject: FYI: pending integrations Message-ID: <1C13B28F-79A6-46DA-9FA9-EF74992B8A4B@oracle.com> (There are more to come, also. -- John) Begin forwarded message: From: John Rose Date: September 5, 2010 12:04:31 AM PDT To: hotspot compiler Subject: Request for review (S): 6953246: JSR 292 should support SAM conversion One important API point in MethodHandles: A SAM constructor for method handles. http://cr.openjdk.java.net/~jrose/6953246/webrev.00/ Begin forwarded message: From: John Rose Date: September 5, 2010 12:01:49 AM PDT To: hotspot compiler Subject: Request for review (M): 6980096: JSR 292 reflective lookup should throw checked exceptions This one changes method handle lookups to throw checked exceptions: http://cr.openjdk.java.net/~jrose/6980096/webrev.00/ -- John Begin forwarded message: From: John Rose Date: September 5, 2010 12:00:14 AM PDT To: hotspot compiler Subject: Re: Request for review (L): 6964498: JSR 292 invokedynamic sites need local bootstrap methods Over the next week or two I am pushing a series of JDK changes for the JSR 292 API. Like previous changes, many are coordinated with JVM changes. Some are purely Java changes. The JVM changes for 6964498 were pushed 7 weeks ago. Here are the associated JDK changes: http://cr.openjdk.java.net/~jrose/6964498/jdk-webrev.01 There are other changes mixed with this, and more to come also. -- John From forax at univ-mlv.fr Sun Sep 5 06:37:51 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 05 Sep 2010 15:37:51 +0200 Subject: Request for review (S): 6953246: JSR 292 should support SAM conversion In-Reply-To: <5C3F9187-F3D4-4681-97BE-A8D669FBCCD3@oracle.com> References: <5C3F9187-F3D4-4681-97BE-A8D669FBCCD3@oracle.com> Message-ID: <4C839D2F.4030904@univ-mlv.fr> Le 05/09/2010 09:04, John Rose a ?crit : > One important API point in MethodHandles: A SAM constructor for method handles. > > http://cr.openjdk.java.net/~jrose/6953246/webrev.00/ > > The answer to the question "Should we delegate equals/hashCode to the targets?" The answer is no ! hashcode should be System.identityHashCode(proxy) equals should be proxy == args[0] and toString() should returns getClass().getName() + '@' + Integer.toHexString(hashCode()). i.e the proxy must simulate the fact that the SAM inherits from java.lang.Object. R?mi From john.r.rose at oracle.com Tue Sep 7 17:04:40 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 08 Sep 2010 00:04:40 +0000 Subject: hg: mlvm/mlvm/langtools: meth, indy: coordinate with upcoming changes from tl/langtools Message-ID: <20100908000441.09A08477BF@hg.openjdk.java.net> Changeset: 1b67f18d903f Author: jrose Date: 2010-09-07 17:04 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/1b67f18d903f meth, indy: coordinate with upcoming changes from tl/langtools ! indy-bsm-6964498.patch ! meth-cast-6979683.patch ! meth-edrfix-6979327.patch + meth-edrfix-mlvm-only.patch ! series From john.r.rose at oracle.com Wed Sep 8 19:02:12 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 09 Sep 2010 02:02:12 +0000 Subject: hg: mlvm/mlvm/jdk: meth, indy: update to reflect current and forthcoming pushes Message-ID: <20100909020212.8600D47825@hg.openjdk.java.net> Changeset: 1172e39510b8 Author: jrose Date: 2010-09-08 19:02 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/1172e39510b8 meth, indy: update to reflect current and forthcoming pushes ! indy-bsm-6964498.patch + indy-dep-6982754.patch ! meth-conv-6939861.patch + meth-cval-6982752.patch ! meth-edrfix-6979327.patch ! meth-lookup-6980096.patch ! meth-proxy-6953246.patch ! meth.patch ! series From john.r.rose at oracle.com Wed Sep 8 20:36:04 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 09 Sep 2010 03:36:04 +0000 Subject: hg: mlvm/mlvm/jdk: meth: add unit test to ClassValue Message-ID: <20100909033604.D435C4782B@hg.openjdk.java.net> Changeset: 3a789791a637 Author: jrose Date: 2010-09-08 20:35 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/3a789791a637 meth: add unit test to ClassValue ! meth-cval-6982752.patch From john.r.rose at oracle.com Sun Sep 12 03:11:22 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 12 Sep 2010 03:11:22 -0700 Subject: review request (L): 6981777 implement JSR 292 EG adjustments from summer 2010 Message-ID: 6981777: implement JSR 292 EG adjustments from summer 2010 Summary: Introduce one more constant pool type, CONSTANT_MethodApply. This JVM change implements a mechanism which supports computed constants and parameterized bootstrap methods: http://cr.openjdk.java.net/~jrose/6981777/webrev.00 The JVM change supplies a "hook" for memoizing library-defined constants in the constant pool. The actual semantics of the hook (which combines a "function" constant with an "argument" constant) will be defined by a JDK runtime routine which invokes the function on the argument if it is a unary function, and otherwise calls MethodHandles.bindTo, effectually treating the function as if it were curried. The code will be something like: apply(fun,arg) := fun.type.parameterCount == 1 ? fun.invokeGeneric(arg) : fun.bindTo(arg); Combined with the pre-existing CONSTANT_MethodHandle constant pool entries, this provides a way to get a wide variety of computed constants. Although it may seem odd to allow only one argument (and use the bindTo function to collect multiple arguments) this design matches better with the binary constant pool structure already commonly built into JVMs, including both the HotSpot and IBM JVMs. The JVM change includes logic to ensure that if the initial computation of a constant causes an exception, this exception will be uniformly thrown from all points where it is referenced. This logic applies to pre-existing constants also. Motivation: Parameterized bootstrap methods seem to be required for factoring closures and similar data structures into distinct static and dynamic specifications. The computed constants allow explicit one-time computation of static information, to be used by an ldc or a bootstrap method or both. Such "live constants" were a request from dynamic language implementors at the Summit. A key use case for one-time computation appears to be representation selection for closures. This is best done in a runtime (decoupled from the bytecode compiler), but should not be done on every closure creation. The invokedynamic instruction can use bootstrap methods with additional parameters supplied by this mechanism to combine prepared closure bodies with closure parameters. The same pattern can also be used by other language implementations which also need to combine static with dynamic data. -- John P.S. I expect one more significant JVM change coming this week: It is the hook for MethodHandles.invokeGeneric, which enables the JVM to perform dynamic argument transformations during method handle invocations. From john.r.rose at oracle.com Sun Sep 12 03:22:35 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 12 Sep 2010 10:22:35 +0000 Subject: hg: mlvm/mlvm/hotspot: meth, indy: update to current RI review requests Message-ID: <20100912102236.B646A478FE@hg.openjdk.java.net> Changeset: 77acbf6c0d2c Author: jrose Date: 2010-09-12 03:22 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/77acbf6c0d2c meth, indy: update to current RI review requests + cpindex-oopmap.patch + meth-api-6981777.patch ! meth-conv-6939861.patch + meth-ing-6939224.patch ! meth.patch ! series From john.r.rose at oracle.com Sun Sep 12 03:22:58 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 12 Sep 2010 10:22:58 +0000 Subject: hg: mlvm/mlvm/jdk: meth, indy: update to current RI review requests Message-ID: <20100912102258.5BCE3478FF@hg.openjdk.java.net> Changeset: a89c3d173ef7 Author: jrose Date: 2010-09-12 03:22 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a89c3d173ef7 meth, indy: update to current RI review requests + meth-api-6981777.patch ! meth-conv-6939861.patch ! meth-edrfix-6979327.patch + meth-ing-6939224.patch ! meth.patch ! series From john.r.rose at oracle.com Sun Sep 12 03:21:47 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 12 Sep 2010 03:21:47 -0700 Subject: FYI: pending RI changes Message-ID: FYI: I CC-ed two review requests for the JSR 292 reference implementation to this list. -- John From john.r.rose at oracle.com Sun Sep 12 03:18:32 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 12 Sep 2010 03:18:32 -0700 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions Message-ID: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions Until now, the HotSpot JVM has conflated invokeExact with invokeGeneric. These changes, combined with forthcoming JDK runtime support changes, provide a hook for the JVM to perform on-the-fly argument conversions in invokeGeneric calls, as specified by the JSR 292 EG. http://cr.openjdk.java.net/~jrose/6939224/webrev.00/ This review is for the JDK parts, which (a) distinguishes correctly between the two invocation modes, and (b) performs an upcall to Java code when argument types need matching. -- John From oehrstroem at gmail.com Mon Sep 13 03:05:54 2010 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 13 Sep 2010 12:05:54 +0200 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions In-Reply-To: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> References: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> Message-ID: Why do an upcall to Java? The conversions should be so simple that it should be possible to handle them in the interpreter. 2010/9/12 John Rose : > 6939224: MethodHandle.invokeGeneric needs to perform the correct set of conversions > > Until now, the HotSpot JVM has conflated invokeExact with invokeGeneric. ?These changes, combined with forthcoming JDK runtime support changes, provide a hook for the JVM to perform on-the-fly argument conversions in invokeGeneric calls, as specified by the JSR 292 EG. > > http://cr.openjdk.java.net/~jrose/6939224/webrev.00/ > > This review is for the JDK parts, which (a) distinguishes correctly between the two invocation modes, and (b) performs an upcall to Java code when argument types need matching. > > -- John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From john.r.rose at oracle.com Mon Sep 13 11:36:10 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Mon, 13 Sep 2010 11:36:10 -0700 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions In-Reply-To: References: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> Message-ID: There is no up-call. The JVM just tail-calls an adapter previously prepared by the JDK runtime. So the interpreter has no special paths other than the slow path with the tail call. I think your implementation put the adapter on a method header. I put it on the method type family (the "form"). -- John (on my iPhone) On Sep 13, 2010, at 3:05 AM, Fredrik ?hrstr?m wrote: > Why do an upcall to Java? The conversions should be so simple that it > should be possible to handle them in the interpreter. From john.r.rose at oracle.com Tue Sep 14 02:56:37 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 14 Sep 2010 09:56:37 +0000 Subject: hg: mlvm/mlvm/hotspot: meth, indy: update to current RI review requests Message-ID: <20100914095638.75DB747971@hg.openjdk.java.net> Changeset: 970ce534fe5c Author: jrose Date: 2010-09-14 02:55 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/970ce534fe5c meth, indy: update to current RI review requests ! meth-api-6981777.patch + meth-bcon-6984311.patch ! meth-conv-6939861.patch ! meth-ing-6939224.patch ! series From john.r.rose at oracle.com Tue Sep 14 02:56:54 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 14 Sep 2010 09:56:54 +0000 Subject: hg: mlvm/mlvm/jdk: meth, indy: update to current RI review requests Message-ID: <20100914095655.4678447972@hg.openjdk.java.net> Changeset: 976263a3568b Author: jrose Date: 2010-09-14 02:56 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/976263a3568b meth, indy: update to current RI review requests ! meth-api-6981777.patch + meth-bcon-6984311.patch ! meth-cval-6982752.patch ! meth-ing-6939224.patch ! meth.patch ! series From john.r.rose at oracle.com Tue Sep 14 03:27:22 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Sep 2010 03:27:22 -0700 Subject: review request (L): 6939224 MethodHandle.invokeGeneric needs to perform the correct set of conversions In-Reply-To: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> References: <52F3A325-C0DB-4155-BAE6-45DFB49D696F@oracle.com> Message-ID: This is the Java code which uses the new hook placed in hotspot under this same bug. http://cr.openjdk.java.net/~jrose/6939224/jdk-webrev.00/ -- John From john.r.rose at oracle.com Tue Sep 14 03:26:11 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 14 Sep 2010 10:26:11 +0000 Subject: hg: mlvm/mlvm/jdk: meth: fix bad unit test Message-ID: <20100914102612.5CA9747976@hg.openjdk.java.net> Changeset: be6eddc62342 Author: jrose Date: 2010-09-14 03:25 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/be6eddc62342 meth: fix bad unit test ! meth-ing-6939224.patch From ali.ebrahimi1781 at gmail.com Tue Sep 14 21:20:07 2010 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Wed, 15 Sep 2010 07:50:07 +0330 Subject: hg: mlvm/mlvm/jdk: meth, indy: update to current RI review requests In-Reply-To: References: Message-ID: Hi John, In method linkMethodHandleConstant in sun/dyn/MethodHandleNatives.java static Object linkMethodHandleConstant(Class callerClass, Object fun, Object arg) { try { MethodHandle mh = ((MethodHandleProvider) fun).asMethodHandle(); if (mh.type().parameterCount() > 1) return mh.bindTo(arg); mh.asType(MethodType.genericMethodType(1)); <======================== this line is OK? return mh.invokeExact(arg); } catch (Throwable ex) { Error err = new IncompatibleClassChangeError(); err.initCause(ex); throw err; } } } this line does not return new object? Best Regards, Ali Ebrahimi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100915/6772bbc5/attachment.html From john.r.rose at oracle.com Tue Sep 14 21:56:54 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 14 Sep 2010 21:56:54 -0700 Subject: hg: mlvm/mlvm/jdk: meth, indy: update to current RI review requests In-Reply-To: References: Message-ID: Thanks for the comment. You are right, it is a bug. Should be "mh = mh.asType...". Best wishes, -- John On Sep 14, 2010, at 9:20 PM, Ali Ebrahimi wrote: > Hi John, > > In method linkMethodHandleConstant in sun/dyn/MethodHandleNatives.java > > > static Object linkMethodHandleConstant(Class callerClass, Object fun, Object arg) { > try { > MethodHandle mh = ((MethodHandleProvider) fun).asMethodHandle(); > if (mh.type().parameterCount() > 1) > return mh.bindTo(arg); > mh.asType(MethodType.genericMethodType(1)); <======================== this line is OK? > return mh.invokeExact(arg); > } catch (Throwable ex) { > Error err = new IncompatibleClassChangeError(); > err.initCause(ex); > throw err; > } > } > } > > this line does not return new object? > > Best Regards, > Ali Ebrahimi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From john.r.rose at oracle.com Tue Sep 14 23:18:22 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 15 Sep 2010 06:18:22 +0000 Subject: hg: mlvm/mlvm/jdk: meth: update to current RI review requests Message-ID: <20100915061822.80BA0479AE@hg.openjdk.java.net> Changeset: 809e4b9b9a81 Author: jrose Date: 2010-09-14 23:18 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/809e4b9b9a81 meth: update to current RI review requests ! meth-bcon-6984311.patch ! meth-ing-6939224.patch From john.r.rose at oracle.com Tue Sep 14 23:22:15 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 15 Sep 2010 06:22:15 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: update to current RI review requests Message-ID: <20100915062215.62EDD479AF@hg.openjdk.java.net> Changeset: ea50a892ee45 Author: jrose Date: 2010-09-14 23:22 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ea50a892ee45 meth: update to current RI review requests ! meth-bcon-6984311.patch From john.r.rose at oracle.com Wed Sep 22 14:23:48 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Sep 2010 14:23:48 -0700 Subject: JavaOne meet-up? Message-ID: I am available for conversation about JVM futures (JSR 292 and MLVM) this afternoon and tomorrow. At about 3:30, I will be hanging around the JavaOne tent by the Hilton. RSVP in case we relocate. I'm especially eager to hear people's comments on the JSR 292 work. Much of it is already in the OpenJDK source base, and will therefore be frozen into the JDK 7 Reference Implementation in a matter of weeks. This is the time to make sure we're not leaving out any good design tweaks. (Of course, we are leaving out big things like tail call and interface injection. I'm talking about the details of the method handle API and invokedynamic design.) Current reference draft (which is close to what's in the OpenJDK): http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/ Best wishes, -- John From headius at headius.com Thu Sep 23 15:57:59 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 23 Sep 2010 17:57:59 -0500 Subject: JavaOne meet-up? In-Reply-To: References: Message-ID: Sorry, I missed this! We've not really been hanging out at JavaOne because of the total logistical failure of having talks spread across several hotels and rescheduling and/or moving most of them the week before the event. I'm really hoping that I can get back to indy stuff in JRuby soon...I guess I've been waiting on ASM, since what I have now still sort-of works and the next step will be to update all the way to the newest stuff. I'm also looking to explore whether it's possible to get equivalent performance out of Remi's backport if we totally control the code generation and classloading logic (i.e. the way JRuby works right now). We would move straight to indy for everything if that's possible, which would make it a lot more compelling (I'd *love* to just delete all the crap we have to do right now). On Wed, Sep 22, 2010 at 4:23 PM, John Rose wrote: > I am available for conversation about JVM futures (JSR 292 and MLVM) this afternoon and tomorrow. > > At about 3:30, I will be hanging around the JavaOne tent by the Hilton. ?RSVP in case we relocate. > > I'm especially eager to hear people's comments on the JSR 292 work. ?Much of it is already in the OpenJDK source base, and will therefore be frozen into the JDK 7 Reference Implementation in a matter of weeks. ?This is the time to make sure we're not leaving out any good design tweaks. > > (Of course, we are leaving out big things like tail call and interface injection. ?I'm talking about the details of the method handle API and invokedynamic design.) > > Current reference draft (which is close to what's in the OpenJDK): > ?http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/ > > Best wishes, > -- John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From christian.thalinger at oracle.com Fri Sep 24 04:16:41 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 24 Sep 2010 13:16:41 +0200 Subject: JavaOne meet-up? In-Reply-To: References: Message-ID: <1285327001.15396.377.camel@macbook> On Thu, 2010-09-23 at 17:57 -0500, Charles Oliver Nutter wrote: > Sorry, I missed this! We've not really been hanging out at JavaOne > because of the total logistical failure of having talks spread across > several hotels and rescheduling and/or moving most of them the week > before the event. I'm really hoping that I can get back to indy stuff > in JRuby soon...I guess I've been waiting on ASM, since what I have > now still sort-of works and the next step will be to update all the > way to the newest stuff. > > I'm also looking to explore whether it's possible to get equivalent > performance out of Remi's backport if we totally control the code > generation and classloading logic (i.e. the way JRuby works right > now). We would move straight to indy for everything if that's > possible, which would make it a lot more compelling (I'd *love* to > just delete all the crap we have to do right now). That sounds good. Any time-frame when you get to do it? I'd like to use JRuby again as testing kit for our latest changes. -- Christian From forax at univ-mlv.fr Fri Sep 24 06:23:12 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 24 Sep 2010 15:23:12 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285327001.15396.377.camel@macbook> References: <1285327001.15396.377.camel@macbook> Message-ID: <4C9CA640.4040909@univ-mlv.fr> Le 24/09/2010 13:16, Christian Thalinger a ?crit : > On Thu, 2010-09-23 at 17:57 -0500, Charles Oliver Nutter wrote: >> Sorry, I missed this! We've not really been hanging out at JavaOne >> because of the total logistical failure of having talks spread across >> several hotels and rescheduling and/or moving most of them the week >> before the event. I'm really hoping that I can get back to indy stuff >> in JRuby soon...I guess I've been waiting on ASM, since what I have >> now still sort-of works and the next step will be to update all the >> way to the newest stuff. >> >> I'm also looking to explore whether it's possible to get equivalent >> performance out of Remi's backport if we totally control the code >> generation and classloading logic (i.e. the way JRuby works right >> now). We would move straight to indy for everything if that's >> possible, which would make it a lot more compelling (I'd *love* to >> just delete all the crap we have to do right now). > That sounds good. Any time-frame when you get to do it? I'd like to > use JRuby again as testing kit for our latest changes. Charles, I've added a way to totally avoid reflection in latest revision of the backport (not in a release yet). This should be an equivalent to your stubs but generated at runtime. So now, even if you don't use the agent at runtime your should have correct performance (I hope). Christian, you can also test with PHP.reboot http://code.google.com/p/phpreboot/ tests are here: http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test The runtime also provides an ahead of time compiler that generates bytecode classes: bin/phpr.sh -aot test/testfibo.phpr I'm also currently working on the next release of ASM (4.0) but I've trouble to find spare time. > -- Christian R?mi From hannes at helma.at Fri Sep 24 11:57:33 2010 From: hannes at helma.at (Hannes Wallnoefer) Date: Fri, 24 Sep 2010 20:57:33 +0200 Subject: JavaOne meet-up? In-Reply-To: References: Message-ID: I was nowhere near JavaOne, but I really enjoyed the slides from your Thundering Rhinos talk. I'm a Rhino developer and would love to start experimenting with the MLVM, but am a bit lost how to build it - or can I simply use the latest official JDK7 beta build? I'm on x86 Linux. Any help is greatly appreciated! Hannes 2010/9/22 John Rose : > I am available for conversation about JVM futures (JSR 292 and MLVM) this afternoon and tomorrow. > > At about 3:30, I will be hanging around the JavaOne tent by the Hilton. ?RSVP in case we relocate. > > I'm especially eager to hear people's comments on the JSR 292 work. ?Much of it is already in the OpenJDK source base, and will therefore be frozen into the JDK 7 Reference Implementation in a matter of weeks. ?This is the time to make sure we're not leaving out any good design tweaks. > > (Of course, we are leaving out big things like tail call and interface injection. ?I'm talking about the details of the method handle API and invokedynamic design.) > > Current reference draft (which is close to what's in the OpenJDK): > ?http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/ > > Best wishes, > -- John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From christian.thalinger at oracle.com Fri Sep 24 12:24:44 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 24 Sep 2010 21:24:44 +0200 Subject: JavaOne meet-up? In-Reply-To: <4C9CA640.4040909@univ-mlv.fr> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> Message-ID: <1285356284.15396.896.camel@macbook> On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: > Christian, you can also test with PHP.reboot > http://code.google.com/p/phpreboot/ > tests are here: > > http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test > > The runtime also provides an ahead of time compiler that generates > bytecode classes: > bin/phpr.sh -aot test/testfibo.phpr Thanks for the hint, I'll give it a try. -- Christian From john.r.rose at oracle.com Fri Sep 24 14:41:13 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 24 Sep 2010 14:41:13 -0700 Subject: JavaOne meet-up? In-Reply-To: References: Message-ID: <76FCE4F0-5DBB-4FCB-BC39-E63EDE1BD357@oracle.com> On Sep 24, 2010, at 11:57 AM, Hannes Wallnoefer wrote: > Can I simply use the latest official JDK7 beta build? I'm on x86 > Linux. Any help is greatly appreciated! In general, the JDK7 beta builds are not far behind the mlvm patch set, for JSR 292 work. (By "not far" I mean a matter of several weeks.) And since the API is stabilizing, any remaining differences will matter less over time. So, yes, the official JDK7 build is a good version to work with. To see what's "in the queue", look at the series files: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/series http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/series -- John From john.r.rose at oracle.com Fri Sep 24 16:10:40 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 24 Sep 2010 23:10:40 +0000 Subject: hg: mlvm/mlvm: 8 new changesets Message-ID: <20100924231040.CC81047BFF@hg.openjdk.java.net> Changeset: ea314633878b Author: jrose Date: 2010-09-24 11:41 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/ea314633878b meth: convert this test for 6979327 ! netbeans/meth/test/sun/dyn/util/ValueConversionsTest.java Changeset: 6552594edb94 Author: jrose Date: 2010-09-24 14:27 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/6552594edb94 indy: convert demos for recent changes (6979327, 6980096) ! netbeans/indy-demo/src/FidgetDemo.java ! netbeans/indy-demo/src/GetNameDemo.java ! netbeans/indy-demo/src/Hello.java ! netbeans/indy-demo/src/JavaDocExamples.java ! netbeans/indy-demo/src/Main.java ! netbeans/indy-demo/src/PrintArgsDemo.java ! netbeans/indy-demo/src/ShouldNotWork.java ! netbeans/indy-demo/src/VMILDemos.java Changeset: 82062030d68e Author: jrose Date: 2010-09-24 14:32 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/82062030d68e meth: convert tests for 6979327 ! netbeans/meth/test/jdk/java/dyn/JUnitAssert.java ! netbeans/meth/test/jdk/java/dyn/MethodHandleBytecodeTest.java ! netbeans/meth/test/jdk/java/dyn/MethodHandleDemo.java ! netbeans/meth/test/jdk/java/dyn/MethodHandleSyntax.java ! netbeans/meth/test/jdk/java/dyn/MethodTypeTest.java Changeset: bd8323fd8671 Author: jrose Date: 2010-09-24 14:33 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/bd8323fd8671 meth: remove unconverted tests - netbeans/meth/test/jdk/java/dyn/HelloDynamic.java - netbeans/meth/test/jdk/java/dyn/InvokeDynamicDemo.java Changeset: 78d102a4afcb Author: jrose Date: 2010-09-24 14:39 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/78d102a4afcb meth: remove obsolete tests - netbeans/meth/test/jdk/java/dyn/JUnitAssert.java - netbeans/meth/test/jdk/java/dyn/MethodHandleBytecodeTest.java - netbeans/meth/test/jdk/java/dyn/MethodHandleDemo.java - netbeans/meth/test/jdk/java/dyn/MethodHandleSyntax.java - netbeans/meth/test/jdk/java/dyn/MethodTypeTest.java Changeset: da6ec495ff07 Author: jrose Date: 2010-09-24 14:57 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/da6ec495ff07 meth: add appendix to javadoc ! netbeans/meth/build.xml Changeset: 587e815d5aa9 Author: jrose Date: 2010-09-24 16:09 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/587e815d5aa9 indy: convert demos for recent changes (6979327, 6980096) ! netbeans/indy-demo/src/FidgetDemo.java ! netbeans/indy-demo/src/GetNameDemo.java ! netbeans/indy-demo/src/Hello.java ! netbeans/indy-demo/src/JavaDocExamples.java ! netbeans/indy-demo/src/PrintArgsDemo.java ! netbeans/indy-demo/src/ShouldNotWork.java ! netbeans/indy-demo/src/VMILDemos.java ! netbeans/indy-demo/src/recipes/FastAndSlow.java ! netbeans/indy-demo/src/recipes/PlainOldJava.java ! netbeans/indy-demo/src/recipes/Utensil.java Changeset: eec0548a4c84 Author: jrose Date: 2010-09-24 16:10 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/eec0548a4c84 indy, meth: update project structure ! netbeans/indy-demo/build.xml ! netbeans/indy-demo/nbproject/project.properties ! netbeans/meth/build.xml ! netbeans/meth/nbproject/project.properties From hannes at helma.at Sat Sep 25 01:04:13 2010 From: hannes at helma.at (Hannes Wallnoefer) Date: Sat, 25 Sep 2010 10:04:13 +0200 Subject: JavaOne meet-up? In-Reply-To: <76FCE4F0-5DBB-4FCB-BC39-E63EDE1BD357@oracle.com> References: <76FCE4F0-5DBB-4FCB-BC39-E63EDE1BD357@oracle.com> Message-ID: 2010/9/24 John Rose : > On Sep 24, 2010, at 11:57 AM, Hannes Wallnoefer wrote: > >> Can I simply use the latest official JDK7 beta build? I'm on x86 >> Linux. Any help is greatly appreciated! > > In general, the JDK7 beta builds are not far behind the mlvm patch set, for JSR 292 work. ?(By "not far" I mean a matter of several weeks.) ?And since the API is stabilizing, any remaining differences will matter less over time. > > So, yes, the official JDK7 build is a good version to work with. Thanks! Glad I can skip the build, it looked somewhat daunting. Hannes > To see what's "in the queue", look at the series files: > ?http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/series > ?http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/series > > -- John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From christian.thalinger at oracle.com Sat Sep 25 03:35:26 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Sat, 25 Sep 2010 12:35:26 +0200 Subject: JavaOne meet-up? In-Reply-To: References: <76FCE4F0-5DBB-4FCB-BC39-E63EDE1BD357@oracle.com> Message-ID: <1285410926.15396.1138.camel@macbook> On Sat, 2010-09-25 at 10:04 +0200, Hannes Wallnoefer wrote: > 2010/9/24 John Rose : > > On Sep 24, 2010, at 11:57 AM, Hannes Wallnoefer wrote: > > > >> Can I simply use the latest official JDK7 beta build? I'm on x86 > >> Linux. Any help is greatly appreciated! > > > > In general, the JDK7 beta builds are not far behind the mlvm patch set, for JSR 292 work. (By "not far" I mean a matter of several weeks.) And since the API is stabilizing, any remaining differences will matter less over time. > > > > So, yes, the official JDK7 build is a good version to work with. > > Thanks! Glad I can skip the build, it looked somewhat daunting. Please let me know when you hit any issues. I'm currently in bug-fixing mode. -- Christian From forax at univ-mlv.fr Sat Sep 25 09:42:46 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 25 Sep 2010 18:42:46 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285410926.15396.1138.camel@macbook> References: <76FCE4F0-5DBB-4FCB-BC39-E63EDE1BD357@oracle.com> <1285410926.15396.1138.camel@macbook> Message-ID: <4C9E2686.7050408@univ-mlv.fr> Le 25/09/2010 12:35, Christian Thalinger a ?crit : > On Sat, 2010-09-25 at 10:04 +0200, Hannes Wallnoefer wrote: > >> 2010/9/24 John Rose: >> >>> On Sep 24, 2010, at 11:57 AM, Hannes Wallnoefer wrote: >>> >>> >>>> Can I simply use the latest official JDK7 beta build? I'm on x86 >>>> Linux. Any help is greatly appreciated! >>>> >>> In general, the JDK7 beta builds are not far behind the mlvm patch set, for JSR 292 work. (By "not far" I mean a matter of several weeks.) And since the API is stabilizing, any remaining differences will matter less over time. >>> >>> So, yes, the official JDK7 build is a good version to work with. >>> >> Thanks! Glad I can skip the build, it looked somewhat daunting. >> > Please let me know when you hit any issues. I'm currently in bug-fixing > mode. > Hi Christian, good to know :) The JVM (jdk7b111) crashes with this error: # Internal Error (javaCalls.cpp:37), pid=16939, tid=6716272 # guarantee(!thread->is_Compiler_thread()) failed: cannot make java calls from the compiler It seems there is an upcall to Java when JITing, the full error log is available in the attached zip file. Step to reproduce, uncompress the src.zip files and run in src: java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic Main The Main.class uses the new LDC MethodHandle, but I'm not sure it's the cause of this error. If you want to recompile something, you need to get the latest java compiler from the lambda workspace with a one line patch that enables function types. I can send you the jar, if you want it. > -- Christian > R?mi -------------- next part -------------- A non-text attachment was scrubbed... Name: src.zip Type: application/zip Size: 14765 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100925/4bba07f7/attachment-0001.zip From forax at univ-mlv.fr Sat Sep 25 11:15:36 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 25 Sep 2010 20:15:36 +0200 Subject: Flag EnableInvokeDynamic hurt performance ? Message-ID: <4C9E3C48.4010607@univ-mlv.fr> Is it a known issue ? I compute the sum of an array values using the fork/join framework without a method handle nor an invokedynamic. Enabling invokedynamic make the test 10 times slower, hugh ? R?mi [forax at localhost src]$ java -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic Main2 1.0E7 in 271589951 ns 1.0E7 in 237457112 ns 1.0E7 in 240127283 ns 1.0E7 in 217190077 ns 1.0E7 in 218797753 ns 1.0E7 in 220700928 ns 1.0E7 in 223629792 ns 1.0E7 in 216456113 ns 1.0E7 in 215407307 ns 1.0E7 in 217131827 ns 1.0E7 in 217560651 ns 1.0E7 in 217247624 ns 1.0E7 in 223484101 ns 1.0E7 in 224640183 ns 1.0E7 in 220751071 ns 1.0E7 in 222363286 ns 1.0E7 in 229409856 ns 1.0E7 in 228857619 ns 1.0E7 in 215848071 ns 1.0E7 in 215329361 ns [forax at localhost src]$ java Main2 1.0E7 in 39480024 ns 1.0E7 in 18961421 ns 1.0E7 in 26926821 ns 1.0E7 in 27624046 ns 1.0E7 in 27361373 ns 1.0E7 in 30849248 ns 1.0E7 in 23242483 ns 1.0E7 in 25827938 ns 1.0E7 in 29493698 ns 1.0E7 in 28450758 ns 1.0E7 in 25993951 ns 1.0E7 in 26795379 ns 1.0E7 in 24874115 ns 1.0E7 in 23357791 ns 1.0E7 in 22871696 ns 1.0E7 in 28331538 ns 1.0E7 in 29761050 ns 1.0E7 in 29115157 ns 1.0E7 in 28256809 ns 1.0E7 in 27554623 ns From forax at univ-mlv.fr Sat Sep 25 11:28:27 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 25 Sep 2010 20:28:27 +0200 Subject: Flag EnableInvokeDynamic hurt performance ? In-Reply-To: <4C9E3C48.4010607@univ-mlv.fr> References: <4C9E3C48.4010607@univ-mlv.fr> Message-ID: <4C9E3F4B.3070200@univ-mlv.fr> Forget to join the test case :) R?mi Le 25/09/2010 20:15, R?mi Forax a ?crit : > Is it a known issue ? > > I compute the sum of an array values using the fork/join framework > without a method handle nor an invokedynamic. > Enabling invokedynamic make the test 10 times slower, hugh ? > > R?mi > > [forax at localhost src]$ java -XX:+UnlockExperimentalVMOptions > -XX:+EnableInvokeDynamic Main5 > 1.0E7 in 271589951 ns > 1.0E7 in 237457112 ns > 1.0E7 in 240127283 ns > 1.0E7 in 217190077 ns > 1.0E7 in 218797753 ns > 1.0E7 in 220700928 ns > 1.0E7 in 223629792 ns > 1.0E7 in 216456113 ns > 1.0E7 in 215407307 ns > 1.0E7 in 217131827 ns > 1.0E7 in 217560651 ns > 1.0E7 in 217247624 ns > 1.0E7 in 223484101 ns > 1.0E7 in 224640183 ns > 1.0E7 in 220751071 ns > 1.0E7 in 222363286 ns > 1.0E7 in 229409856 ns > 1.0E7 in 228857619 ns > 1.0E7 in 215848071 ns > 1.0E7 in 215329361 ns > [forax at localhost src]$ java Main5 > 1.0E7 in 39480024 ns > 1.0E7 in 18961421 ns > 1.0E7 in 26926821 ns > 1.0E7 in 27624046 ns > 1.0E7 in 27361373 ns > 1.0E7 in 30849248 ns > 1.0E7 in 23242483 ns > 1.0E7 in 25827938 ns > 1.0E7 in 29493698 ns > 1.0E7 in 28450758 ns > 1.0E7 in 25993951 ns > 1.0E7 in 26795379 ns > 1.0E7 in 24874115 ns > 1.0E7 in 23357791 ns > 1.0E7 in 22871696 ns > 1.0E7 in 28331538 ns > 1.0E7 in 29761050 ns > 1.0E7 in 29115157 ns > 1.0E7 in 28256809 ns > 1.0E7 in 27554623 ns > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Main5.java Url: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100925/05b19234/attachment.ksh From forax at univ-mlv.fr Sat Sep 25 11:45:28 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 25 Sep 2010 20:45:28 +0200 Subject: Flag EnableInvokeDynamic hurt performance ? In-Reply-To: <4C9E3F4B.3070200@univ-mlv.fr> References: <4C9E3C48.4010607@univ-mlv.fr> <4C9E3F4B.3070200@univ-mlv.fr> Message-ID: <4C9E4348.2070006@univ-mlv.fr> Ok, I've found. Enabling invokedynamic disable escape analysis at runtime/arguments.cpp:2902 2902: if (EnableInvokeDynamic && DoEscapeAnalysis) { 2903- // TODO: We need to find rules for invokedynamic and EA. For now, 2904- // simply disable EA by default. 2905- if (FLAG_IS_DEFAULT(DoEscapeAnalysis)) { 2906- DoEscapeAnalysis = false; John, Christian, is it fixable ? R?mi Le 25/09/2010 20:28, R?mi Forax a ?crit : > Forget to join the test case :) > > R?mi > > Le 25/09/2010 20:15, R?mi Forax a ?crit : >> Is it a known issue ? >> >> I compute the sum of an array values using the fork/join framework >> without a method handle nor an invokedynamic. >> Enabling invokedynamic make the test 10 times slower, hugh ? >> >> R?mi >> >> [forax at localhost src]$ java -XX:+UnlockExperimentalVMOptions >> -XX:+EnableInvokeDynamic Main5 >> 1.0E7 in 271589951 ns >> 1.0E7 in 237457112 ns >> 1.0E7 in 240127283 ns >> 1.0E7 in 217190077 ns >> 1.0E7 in 218797753 ns >> 1.0E7 in 220700928 ns >> 1.0E7 in 223629792 ns >> 1.0E7 in 216456113 ns >> 1.0E7 in 215407307 ns >> 1.0E7 in 217131827 ns >> 1.0E7 in 217560651 ns >> 1.0E7 in 217247624 ns >> 1.0E7 in 223484101 ns >> 1.0E7 in 224640183 ns >> 1.0E7 in 220751071 ns >> 1.0E7 in 222363286 ns >> 1.0E7 in 229409856 ns >> 1.0E7 in 228857619 ns >> 1.0E7 in 215848071 ns >> 1.0E7 in 215329361 ns >> [forax at localhost src]$ java Main5 >> 1.0E7 in 39480024 ns >> 1.0E7 in 18961421 ns >> 1.0E7 in 26926821 ns >> 1.0E7 in 27624046 ns >> 1.0E7 in 27361373 ns >> 1.0E7 in 30849248 ns >> 1.0E7 in 23242483 ns >> 1.0E7 in 25827938 ns >> 1.0E7 in 29493698 ns >> 1.0E7 in 28450758 ns >> 1.0E7 in 25993951 ns >> 1.0E7 in 26795379 ns >> 1.0E7 in 24874115 ns >> 1.0E7 in 23357791 ns >> 1.0E7 in 22871696 ns >> 1.0E7 in 28331538 ns >> 1.0E7 in 29761050 ns >> 1.0E7 in 29115157 ns >> 1.0E7 in 28256809 ns >> 1.0E7 in 27554623 ns >> >> _______________________________________________ >> 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/20100925/b893c5c1/attachment.html From john.r.rose at oracle.com Sat Sep 25 13:03:00 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 25 Sep 2010 13:03:00 -0700 Subject: Flag EnableInvokeDynamic hurt performance ? In-Reply-To: <4C9E4348.2070006@univ-mlv.fr> References: <4C9E3C48.4010607@univ-mlv.fr> <4C9E3F4B.3070200@univ-mlv.fr> <4C9E4348.2070006@univ-mlv.fr> Message-ID: On Sep 25, 2010, at 11:45 AM, R?mi Forax wrote: > John, Christian, is it fixable ? Yes. We're talking about fixing this, soon, as part of 6817525. -- John From forax at univ-mlv.fr Sat Sep 25 13:34:16 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 25 Sep 2010 22:34:16 +0200 Subject: Flag EnableInvokeDynamic hurt performance ? In-Reply-To: References: <4C9E3C48.4010607@univ-mlv.fr> <4C9E3F4B.3070200@univ-mlv.fr> <4C9E4348.2070006@univ-mlv.fr> Message-ID: <4C9E5CC8.2000308@univ-mlv.fr> Le 25/09/2010 22:03, John Rose a ?crit : > On Sep 25, 2010, at 11:45 AM, R?mi Forax wrote: > > >> John, Christian, is it fixable ? >> > Yes. We're talking about fixing this, soon, as part of 6817525. > > -- John > Cool. R?mi From christian.thalinger at oracle.com Mon Sep 27 02:51:13 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 11:51:13 +0200 Subject: JavaOne meet-up? In-Reply-To: <4C9E2686.7050408@univ-mlv.fr> References: <76FCE4F0-5DBB-4FCB-BC39-E63EDE1BD357@oracle.com> <1285410926.15396.1138.camel@macbook> <4C9E2686.7050408@univ-mlv.fr> Message-ID: <1285581073.13584.846.camel@macbook> On Sat, 2010-09-25 at 18:42 +0200, R?mi Forax wrote: > The JVM (jdk7b111) crashes with this error: > # Internal Error (javaCalls.cpp:37), pid=16939, tid=6716272 > # guarantee(!thread->is_Compiler_thread()) failed: cannot make java > calls from the compiler > > It seems there is an upcall to Java when JITing, Kind of. The actual assert with a debug build is: # assert(!THREAD->is_Compiler_thread()) failed: Can not load classes with the Compiler thread A java.lang.LinkageError is to be thrown but it's not loaded yet. Looking into it. -- Christian From forax at univ-mlv.fr Mon Sep 27 03:18:10 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 27 Sep 2010 12:18:10 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285581073.13584.846.camel@macbook> References: <76FCE4F0-5DBB-4FCB-BC39-E63EDE1BD357@oracle.com> <1285410926.15396.1138.camel@macbook> <4C9E2686.7050408@univ-mlv.fr> <1285581073.13584.846.camel@macbook> Message-ID: <4CA06F62.9050601@univ-mlv.fr> Le 27/09/2010 11:51, Christian Thalinger a ?crit : > On Sat, 2010-09-25 at 18:42 +0200, R?mi Forax wrote: >> The JVM (jdk7b111) crashes with this error: >> # Internal Error (javaCalls.cpp:37), pid=16939, tid=6716272 >> # guarantee(!thread->is_Compiler_thread()) failed: cannot make java >> calls from the compiler >> >> It seems there is an upcall to Java when JITing, > Kind of. The actual assert with a debug build is: > > # assert(!THREAD->is_Compiler_thread()) failed: Can not load classes with the Compiler thread > > A java.lang.LinkageError is to be thrown but it's not loaded yet. > Looking into it. So now there is two bugs :) Why a LinkageError is raised and Why it's not loaded yet ? > -- Christian R?mi From chanwit at gmail.com Mon Sep 27 05:52:37 2010 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Mon, 27 Sep 2010 19:52:37 +0700 Subject: Another paper on invokedynamic Message-ID: Dear all, This is another paper on invokedynamic (second to John Rose's :)) to be appeared in VMIL '10: Abstract ======== This paper presents a study of a Java Virtual Machine prototype from the Da Vinci Machine project, defined by JSR 292. It describes binary translation techniques to prepare benchmarks to run on the invokedynamic mode of the prototype, resulting in the invokedynamic version of the SciMark 2.0 suite. Benchmark preparation techniques presented in this paper are proven to be useful as the invokedynamic version of benchmark programs successfully identified strange slowness behavior of the invokedynamic mode of the server virtual machine. Surprisingly, benchmarking results show that the invoke- dynamic mode with direct method handles on the server virtual machine is just 2-5 times slower than native Java invocations, except the Monte Carlo benchmark. But this mode on the client virtual machine still requires further performance tuning. ======== I hope you find it useful somehow and any feedback is very welcome! http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf Best regards, Chanwit From christian.thalinger at Oracle.Com Mon Sep 27 06:20:00 2010 From: christian.thalinger at Oracle.Com (Christian Thalinger) Date: Mon, 27 Sep 2010 15:20:00 +0200 Subject: Another paper on invokedynamic In-Reply-To: References: Message-ID: <1285593600.27094.208.camel@macbook> On Mon, 2010-09-27 at 19:52 +0700, Chanwit Kaewkasi wrote: > I hope you find it useful somehow and any feedback is very welcome! > > http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf Nice read. It would be very interesting why Monte Carlo behaves like that. Did you look closer at it? -- Christian From christian.thalinger at oracle.com Mon Sep 27 06:41:59 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 15:41:59 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285356284.15396.896.camel@macbook> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> Message-ID: <1285594919.27094.232.camel@macbook> On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: > On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: > > Christian, you can also test with PHP.reboot > > http://code.google.com/p/phpreboot/ > > tests are here: > > > > http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test > > > > The runtime also provides an ahead of time compiler that generates > > bytecode classes: > > bin/phpr.sh -aot test/testfibo.phpr > > Thanks for the hint, I'll give it a try. -- Christian That one is odd (with testfibo.phpr): Caused by: java.lang.IllegalArgumentException: bad adapter (conversion=0x00000100): type mismatch: returning a int, but caller expects boolean at sun.dyn.MethodHandleNatives.init(Native Method) at sun.dyn.AdapterMethodHandle.(AdapterMethodHandle.java:53) at sun.dyn.AdapterMethodHandle.(AdapterMethodHandle.java:58) at sun.dyn.AdapterMethodHandle.makeRetype(AdapterMethodHandle.java:478) at sun.dyn.AdapterMethodHandle.makeRetypeRaw(AdapterMethodHandle.java:468) at sun.dyn.ToGeneric.(ToGeneric.java:148) at sun.dyn.ToGeneric.of(ToGeneric.java:257) at sun.dyn.ToGeneric.make(ToGeneric.java:249) at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:808) at java.dyn.MethodHandles.convertArguments(MethodHandles.java:1048) at com.googlecode.phpreboot.runtime.RT.bootstrap(RT.java:1193) at sun.dyn.CallSiteImpl.makeSite(CallSiteImpl.java:53) ... 634 more -- Christian From forax at univ-mlv.fr Mon Sep 27 07:00:01 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 27 Sep 2010 16:00:01 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285594919.27094.232.camel@macbook> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285594919.27094.232.camel@macbook> Message-ID: <4CA0A361.5030707@univ-mlv.fr> Le 27/09/2010 15:41, Christian Thalinger a ?crit : > On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: >> On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: >>> Christian, you can also test with PHP.reboot >>> http://code.google.com/p/phpreboot/ >>> tests are here: >>> >>> http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test >>> >>> The runtime also provides an ahead of time compiler that generates >>> bytecode classes: >>> bin/phpr.sh -aot test/testfibo.phpr >> Thanks for the hint, I'll give it a try. -- Christian > That one is odd (with testfibo.phpr): > > Caused by: java.lang.IllegalArgumentException: bad adapter (conversion=0x00000100): type mismatch: returning a int, but caller expects boolean > at sun.dyn.MethodHandleNatives.init(Native Method) > at sun.dyn.AdapterMethodHandle.(AdapterMethodHandle.java:53) > at sun.dyn.AdapterMethodHandle.(AdapterMethodHandle.java:58) > at sun.dyn.AdapterMethodHandle.makeRetype(AdapterMethodHandle.java:478) > at sun.dyn.AdapterMethodHandle.makeRetypeRaw(AdapterMethodHandle.java:468) > at sun.dyn.ToGeneric.(ToGeneric.java:148) > at sun.dyn.ToGeneric.of(ToGeneric.java:257) > at sun.dyn.ToGeneric.make(ToGeneric.java:249) > at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:808) > at java.dyn.MethodHandles.convertArguments(MethodHandles.java:1048) > at com.googlecode.phpreboot.runtime.RT.bootstrap(RT.java:1193) > at sun.dyn.CallSiteImpl.makeSite(CallSiteImpl.java:53) > ... 634 more I'll take a look to see If it's me or you :) > -- Christian R?mi From oehrstroem at gmail.com Mon Sep 27 07:27:33 2010 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 27 Sep 2010 16:27:33 +0200 Subject: Another paper on invokedynamic In-Reply-To: References: Message-ID: Interesting paper. It is good to have a test to verify that Direct MethodHandles installed into the CallSites should have (almost) identical performance as the original code. Obviously we are not quite there yet. I do think it is any use in making super() link very late. It would only make sense if you could change the inheritance hierarchy very late, which you can't. //Fredrik 2010/9/27 Chanwit Kaewkasi > Dear all, > > This is another paper on invokedynamic (second to John Rose's :)) to > be appeared in VMIL '10: > > Abstract > ======== > This paper presents a study of a Java Virtual Machine prototype > from the Da Vinci Machine project, defined by JSR 292. It > describes binary translation techniques to prepare benchmarks to > run on the invokedynamic mode of the prototype, resulting > in the invokedynamic version of the SciMark 2.0 suite. > Benchmark preparation techniques presented in this paper are > proven to be useful as the invokedynamic version of > benchmark programs successfully identified strange slowness > behavior of the invokedynamic mode of the server virtual > machine. > > Surprisingly, benchmarking results show that the invoke- > dynamic mode with direct method handles on the server > virtual machine is just 2-5 times slower than native Java > invocations, except the Monte Carlo benchmark. But this mode > on the client virtual machine still requires further performance > tuning. > ======== > > I hope you find it useful somehow and any feedback is very welcome! > > http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf > > Best regards, > > Chanwit > _______________________________________________ > 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/20100927/6c428cb4/attachment.html From forax at univ-mlv.fr Mon Sep 27 07:35:56 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 27 Sep 2010 16:35:56 +0200 Subject: JavaOne meet-up? In-Reply-To: <4CA0A361.5030707@univ-mlv.fr> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285594919.27094.232.camel@macbook> <4CA0A361.5030707@univ-mlv.fr> Message-ID: <4CA0ABCC.6030207@univ-mlv.fr> Le 27/09/2010 16:00, R?mi Forax a ?crit : > Le 27/09/2010 15:41, Christian Thalinger a ?crit : > >> On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: >> >>> On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: >>> >>>> Christian, you can also test with PHP.reboot >>>> http://code.google.com/p/phpreboot/ >>>> tests are here: >>>> >>>> http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test >>>> >>>> The runtime also provides an ahead of time compiler that generates >>>> bytecode classes: >>>> bin/phpr.sh -aot test/testfibo.phpr >>>> >>> Thanks for the hint, I'll give it a try. -- Christian >>> >> That one is odd (with testfibo.phpr): >> >> Caused by: java.lang.IllegalArgumentException: bad adapter (conversion=0x00000100): type mismatch: returning a int, but caller expects boolean >> at sun.dyn.MethodHandleNatives.init(Native Method) >> at sun.dyn.AdapterMethodHandle.(AdapterMethodHandle.java:53) >> at sun.dyn.AdapterMethodHandle.(AdapterMethodHandle.java:58) >> at sun.dyn.AdapterMethodHandle.makeRetype(AdapterMethodHandle.java:478) >> at sun.dyn.AdapterMethodHandle.makeRetypeRaw(AdapterMethodHandle.java:468) >> at sun.dyn.ToGeneric.(ToGeneric.java:148) >> at sun.dyn.ToGeneric.of(ToGeneric.java:257) >> at sun.dyn.ToGeneric.make(ToGeneric.java:249) >> at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:808) >> at java.dyn.MethodHandles.convertArguments(MethodHandles.java:1048) >> at com.googlecode.phpreboot.runtime.RT.bootstrap(RT.java:1193) >> at sun.dyn.CallSiteImpl.makeSite(CallSiteImpl.java:53) >> ... 634 more >> > I'll take a look to see If it's me or you :) > The error seems to be when I convert a boolean to boolean ?? $ bin/phpr.sh -aot test/testfibo.phpr testfibo generated ! $java -client -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -Xbootclasspath/p:lib/phpreboot.jar testfibo 17711 $java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -Xbootclasspath/p:lib/phpreboot.jar testfibo # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00fdf409, pid=10925, tid=4844400 # # JRE version: 7.0 # Java VM: Java HotSpot(TM) Server VM (19.0-b06 mixed mode linux-x86 ) # Problematic frame: # V [libjvm.so+0x275409] # # An error report file with more information is saved as: # /home/forax/java/workspace/phpreboot/hs_err_pid10925.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Abandon (core dumped) Hum, I think it's your fault not mine ( ok let's say John's :) I'm on linux 32bits with jdk7 b111. > >> -- Christian >> > R?mi > R?mi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid10925.log Url: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100927/3608f6c3/attachment-0001.ksh From forax at univ-mlv.fr Mon Sep 27 07:30:06 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 27 Sep 2010 16:30:06 +0200 Subject: Another paper on invokedynamic In-Reply-To: <1285593600.27094.208.camel@macbook> References: <1285593600.27094.208.camel@macbook> Message-ID: <4CA0AA6E.6050705@univ-mlv.fr> Le 27/09/2010 15:20, Christian Thalinger a ?crit : > On Mon, 2010-09-27 at 19:52 +0700, Chanwit Kaewkasi wrote: >> I hope you find it useful somehow and any feedback is very welcome! >> >> http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf > Nice read. It would be very interesting why Monte Carlo behaves like > that. Did you look closer at it? I've done the same kind of test, not on SciMark 2.0 but on DaCapo and without rewriting all primitive operators (BTW, I haven't understand why you have re-written it manually). The results was far better but I suppose it's due to the fact that I haven't woven operators. A remark, you don't need to store all method handles in an array, the one you initialize in the static block of each class. Instead of having one boostrap by callsite you can factor them to have one bootstrap by invocation bytecode. > -- Christian R?mi From forax at univ-mlv.fr Mon Sep 27 07:56:45 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 27 Sep 2010 16:56:45 +0200 Subject: JavaOne meet-up? In-Reply-To: <4CA0ABCC.6030207@univ-mlv.fr> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285594919.27094.232.camel@macbook> <4CA0A361.5030707@univ-mlv.fr> <4CA0ABCC.6030207@univ-mlv.fr> Message-ID: <4CA0B0AD.5050700@univ-mlv.fr> Here is a small test case. It crashes with jdk7b111 with c2. Christian could you test with your build ? R?mi ---------------------------------------------------------------------------------------------------------- import java.dyn.CallSite; import java.dyn.InvokeDynamic; import java.dyn.Linkage; import java.dyn.MethodHandle; import java.dyn.MethodHandles; import java.dyn.MethodType; import java.dyn.MethodHandles.Lookup; public class ConvertBooleanBug { public static Object fallback(CallSite callSite, Object left, Object right) { return true; } public static CallSite bootstrap(Class declaringClass, String name, MethodType type) { Lookup lookup = MethodHandles.lookup(); MethodHandle fallback = lookup.findStatic(ConvertBooleanBug.class, "fallback", MethodType.methodType(Object.class, CallSite.class, Object.class, Object.class)); CallSite callSite = new CallSite(); fallback = MethodHandles.insertArguments(fallback, 0, callSite); fallback = MethodHandles.convertArguments(fallback, type); callSite.setTarget(fallback); return callSite; } public static void main(String[] args) throws Throwable { for(int i=0; i<100000; i++) { boolean b = InvokeDynamic.call((Object)1, 2); } } static { Linkage.registerBootstrapMethod("bootstrap"); } } From christian.thalinger at oracle.com Mon Sep 27 07:51:31 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 16:51:31 +0200 Subject: JavaOne meet-up? In-Reply-To: <4CA0ABCC.6030207@univ-mlv.fr> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285594919.27094.232.camel@macbook> <4CA0A361.5030707@univ-mlv.fr> <4CA0ABCC.6030207@univ-mlv.fr> Message-ID: <1285599091.27094.314.camel@macbook> On Mon, 2010-09-27 at 16:35 +0200, R?mi Forax wrote: > The error seems to be when I convert a boolean to boolean ?? > > $ bin/phpr.sh -aot test/testfibo.phpr > testfibo generated ! > > $java -client -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic > -Xbootclasspath/p:lib/phpreboot.jar testfibo > 17711 > > $java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic > -Xbootclasspath/p:lib/phpreboot.jar testfibo > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00fdf409, pid=10925, tid=4844400 > # > # JRE version: 7.0 > # Java VM: Java HotSpot(TM) Server VM (19.0-b06 mixed mode linux-x86 ) > # Problematic frame: > # V [libjvm.so+0x275409] > # > # An error report file with more information is saved as: > # /home/forax/java/workspace/phpreboot/hs_err_pid10925.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Abandon (core dumped) Hmm, that's weird. I can reproduce the behavior above with b111 but with a current HotSpot build (HS20b01) I get the "bad adapter" exception. I hope John knows more about this... -- Christian From christian.thalinger at oracle.com Mon Sep 27 07:56:11 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 16:56:11 +0200 Subject: JavaOne meet-up? In-Reply-To: <4CA0B0AD.5050700@univ-mlv.fr> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285594919.27094.232.camel@macbook> <4CA0A361.5030707@univ-mlv.fr> <4CA0ABCC.6030207@univ-mlv.fr> <4CA0B0AD.5050700@univ-mlv.fr> Message-ID: <1285599371.27094.319.camel@macbook> On Mon, 2010-09-27 at 16:56 +0200, R?mi Forax wrote: > Here is a small test case. > > It crashes with jdk7b111 with c2. > > Christian could you test with your build ? Yes, that produces the same exception. Maybe there is a JDK patch missing? -- Christian From christian.thalinger at oracle.com Mon Sep 27 08:20:05 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 17:20:05 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285356284.15396.896.camel@macbook> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> Message-ID: <1285600805.27094.348.camel@macbook> On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: > On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: > > Christian, you can also test with PHP.reboot > > http://code.google.com/p/phpreboot/ > > tests are here: > > > > http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test > > > > The runtime also provides an ahead of time compiler that generates > > bytecode classes: > > bin/phpr.sh -aot test/testfibo.phpr > > Thanks for the hint, I'll give it a try. -- Christian What about this one: test/testtraceoptimistic.phpr VM option '+UnlockExperimentalVMOptions' VM option '+EnableInvokeDynamic' java.lang.NullPointerException at com.googlecode.phpreboot.interpreter.Profile$LoopProfile.callTrace(Profile.java:42) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:371) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) at com.googlecode.phpreboot.ast.LabeledInstrWhile.accept(LabeledInstrWhile.java:38) at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:273) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) at com.googlecode.phpreboot.ast.InstrLabeled.accept(InstrLabeled.java:38) at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:301) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) at com.googlecode.phpreboot.ast.Block.accept(Block.java:48) at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:251) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) at com.googlecode.phpreboot.ast.Visitor.visit(Visitor.java:87) at com.googlecode.phpreboot.ast.InstrBlock.accept(InstrBlock.java:30) at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:400) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) at com.googlecode.phpreboot.ast.LabeledInstrWhile.accept(LabeledInstrWhile.java:38) at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:273) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) at com.googlecode.phpreboot.ast.InstrLabeled.accept(InstrLabeled.java:38) at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) at com.googlecode.phpreboot.interpreter.Interpreter.eval(Interpreter.java:52) at com.googlecode.phpreboot.interpreter.Interpreter.instr_labeled(Interpreter.java:214) at com.googlecode.phpreboot.tools.AnalyzerProcessor.reduce(AnalyzerProcessor.java:757) at com.googlecode.phpreboot.tools.AnalyzerProcessor.reduce(AnalyzerProcessor.java:129) at fr.umlv.tatoo.runtime.tools.ToolsProcessor.reduce(ToolsProcessor.java:117) at fr.umlv.tatoo.runtime.parser.Parser.performReduce(Parser.java:484) at fr.umlv.tatoo.runtime.parser.Parser.performShift(Parser.java:508) at fr.umlv.tatoo.runtime.parser.ShiftAction.doPerform(ShiftAction.java:23) at fr.umlv.tatoo.runtime.parser.Parser.doStep(Parser.java:402) at fr.umlv.tatoo.runtime.parser.Parser.push(Parser.java:384) at fr.umlv.tatoo.runtime.tools.ToolsProcessor$LexerHandler.ruleVerified(ToolsProcessor.java:87) at fr.umlv.tatoo.runtime.tools.ToolsProcessor$LexerHandler.ruleVerified(ToolsProcessor.java:67) at fr.umlv.tatoo.runtime.lexer.Lexer$LexerImpl.ruleVerified(Lexer.java:143) at fr.umlv.tatoo.runtime.lexer.Lexer$LexerImpl.step(Lexer.java:87) at fr.umlv.tatoo.runtime.lexer.Lexer$LexerImpl.run(Lexer.java:160) at com.googlecode.phpreboot.interpreter.Analyzer.interpret(Analyzer.java:78) at com.googlecode.phpreboot.Main.main(Main.java:187) From stephen.bannasch at deanbrook.org Mon Sep 27 09:17:14 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 27 Sep 2010 12:17:14 -0400 Subject: updated mac build of mlvm, 2010-09-25 Message-ID: FYI: Here's an updated Mac OS X build of mlvm from: 2010-09-25 http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-mlvm-2010_09_25.tar.gz From forax at univ-mlv.fr Mon Sep 27 09:29:10 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 27 Sep 2010 18:29:10 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285600805.27094.348.camel@macbook> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285600805.27094.348.camel@macbook> Message-ID: <4CA0C656.3090207@univ-mlv.fr> Le 27/09/2010 17:20, Christian Thalinger a ?crit : > On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: > >> On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: >> >>> Christian, you can also test with PHP.reboot >>> http://code.google.com/p/phpreboot/ >>> tests are here: >>> >>> http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test >>> >>> The runtime also provides an ahead of time compiler that generates >>> bytecode classes: >>> bin/phpr.sh -aot test/testfibo.phpr >>> >> Thanks for the hint, I'll give it a try. -- Christian >> > What about this one: > This one is my bug :) I've refactored the way to escape from a trace but don't update the code that reuse a trace. My bad. All inner-loops that contains at least an untaken branch will not work. R?mi > test/testtraceoptimistic.phpr > VM option '+UnlockExperimentalVMOptions' > VM option '+EnableInvokeDynamic' > java.lang.NullPointerException > at com.googlecode.phpreboot.interpreter.Profile$LoopProfile.callTrace(Profile.java:42) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:371) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) > at com.googlecode.phpreboot.ast.LabeledInstrWhile.accept(LabeledInstrWhile.java:38) > at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:273) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) > at com.googlecode.phpreboot.ast.InstrLabeled.accept(InstrLabeled.java:38) > at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:301) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) > at com.googlecode.phpreboot.ast.Block.accept(Block.java:48) > at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:251) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) > at com.googlecode.phpreboot.ast.Visitor.visit(Visitor.java:87) > at com.googlecode.phpreboot.ast.InstrBlock.accept(InstrBlock.java:30) > at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:400) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) > at com.googlecode.phpreboot.ast.LabeledInstrWhile.accept(LabeledInstrWhile.java:38) > at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:273) > at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:122) > at com.googlecode.phpreboot.ast.InstrLabeled.accept(InstrLabeled.java:38) > at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:144) > at com.googlecode.phpreboot.interpreter.Interpreter.eval(Interpreter.java:52) > at com.googlecode.phpreboot.interpreter.Interpreter.instr_labeled(Interpreter.java:214) > at com.googlecode.phpreboot.tools.AnalyzerProcessor.reduce(AnalyzerProcessor.java:757) > at com.googlecode.phpreboot.tools.AnalyzerProcessor.reduce(AnalyzerProcessor.java:129) > at fr.umlv.tatoo.runtime.tools.ToolsProcessor.reduce(ToolsProcessor.java:117) > at fr.umlv.tatoo.runtime.parser.Parser.performReduce(Parser.java:484) > at fr.umlv.tatoo.runtime.parser.Parser.performShift(Parser.java:508) > at fr.umlv.tatoo.runtime.parser.ShiftAction.doPerform(ShiftAction.java:23) > at fr.umlv.tatoo.runtime.parser.Parser.doStep(Parser.java:402) > at fr.umlv.tatoo.runtime.parser.Parser.push(Parser.java:384) > at fr.umlv.tatoo.runtime.tools.ToolsProcessor$LexerHandler.ruleVerified(ToolsProcessor.java:87) > at fr.umlv.tatoo.runtime.tools.ToolsProcessor$LexerHandler.ruleVerified(ToolsProcessor.java:67) > at fr.umlv.tatoo.runtime.lexer.Lexer$LexerImpl.ruleVerified(Lexer.java:143) > at fr.umlv.tatoo.runtime.lexer.Lexer$LexerImpl.step(Lexer.java:87) > at fr.umlv.tatoo.runtime.lexer.Lexer$LexerImpl.run(Lexer.java:160) > at com.googlecode.phpreboot.interpreter.Analyzer.interpret(Analyzer.java:78) > at com.googlecode.phpreboot.Main.main(Main.java:187) > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From christian.thalinger at oracle.com Mon Sep 27 11:51:19 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Sep 2010 20:51:19 +0200 Subject: JavaOne meet-up? In-Reply-To: <4CA0C656.3090207@univ-mlv.fr> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285600805.27094.348.camel@macbook> <4CA0C656.3090207@univ-mlv.fr> Message-ID: <1285613479.27094.576.camel@macbook> On Mon, 2010-09-27 at 18:29 +0200, R?mi Forax wrote: > Le 27/09/2010 17:20, Christian Thalinger a ?crit : > > On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: > > > >> On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: > >> > >>> Christian, you can also test with PHP.reboot > >>> http://code.google.com/p/phpreboot/ > >>> tests are here: > >>> > >>> http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test > >>> > >>> The runtime also provides an ahead of time compiler that generates > >>> bytecode classes: > >>> bin/phpr.sh -aot test/testfibo.phpr > >>> > >> Thanks for the hint, I'll give it a try. -- Christian > >> > > What about this one: > > > > This one is my bug :) > I've refactored the way to escape from a trace but don't update the code > that reuse a trace. My bad. > All inner-loops that contains at least an untaken branch will not work. Alright :-) -- Christian From chanwit at gmail.com Mon Sep 27 18:57:00 2010 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Tue, 28 Sep 2010 08:57:00 +0700 Subject: Another paper on invokedynamic In-Reply-To: <1285593600.27094.208.camel@macbook> References: <1285593600.27094.208.camel@macbook> Message-ID: Hi Christian, On Mon, Sep 27, 2010 at 20:20, Christian Thalinger wrote: > On Mon, 2010-09-27 at 19:52 +0700, Chanwit Kaewkasi wrote: >> I hope you find it useful somehow and any feedback is very welcome! >> >> http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf > > Nice read. ?It would be very interesting why Monte Carlo behaves like > that. ?Did you look closer at it? No, I haven't. If you have some a good trick to hunt this kind of bottle necks, I am glad to hear about it. -Chanwit > -- Christian > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From chanwit at gmail.com Mon Sep 27 18:57:29 2010 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Tue, 28 Sep 2010 08:57:29 +0700 Subject: Another paper on invokedynamic In-Reply-To: References: Message-ID: Hi Fredrik, On Mon, Sep 27, 2010 at 21:27, Fredrik ?hrstr?m wrote: > Interesting paper. It is good to have a test to verify that > Direct MethodHandles installed into the CallSites should > have (almost) identical performance as the original code. > Obviously we are not quite there yet. Glad to know that the paper got some good uses :-) > I do think it is any use in making super() link very late. > It would only make sense if you could?change the > inheritance hierarchy very late, which you can't. I am not intended to change class hierarchy at runtime (but it's quite great if we can do that dynamically.) To me, changing behaviour at super() or this() means adding before/after actions (via combinators) for that points. There are some cases that you can use them as a join points in AOP. Please also see the table in this page: http://www.eclipse.org/aspectj/doc/released/progguide/semantics-joinPoints.html -Chanwit > //Fredrik > > 2010/9/27 Chanwit Kaewkasi >> >> Dear all, >> >> This is another paper on invokedynamic (second to John Rose's :)) to >> be appeared in VMIL '10: >> >> Abstract >> ======== >> This paper presents a study of a Java Virtual Machine prototype >> from the Da Vinci Machine project, defined by JSR 292. It >> describes binary translation techniques to prepare benchmarks to >> run on the invokedynamic mode of the prototype, resulting >> in the ?invokedynamic version of the SciMark 2.0 suite. >> Benchmark preparation techniques presented in this paper are >> proven to be useful as the ?invokedynamic version of >> benchmark programs successfully identified strange slowness >> behavior of the ?invokedynamic mode of the server virtual >> machine. >> >> Surprisingly, benchmarking results show that the ?invoke- >> dynamic mode with direct method handles on the server >> virtual machine is just 2-5 times slower than native Java >> invocations, except the Monte Carlo benchmark. But this mode >> on the client virtual machine still requires further performance >> tuning. >> ======== >> >> I hope you find it useful somehow and any feedback is very welcome! >> >> http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf >> >> Best regards, >> >> Chanwit >> _______________________________________________ >> 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 > > -- Dr Chanwit Kaewkasi, Lecturer School of Computer Engineering, Suranaree University of Technology Nakhon Ratchasima, Thailand 30000 From chanwit at gmail.com Mon Sep 27 18:57:46 2010 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Tue, 28 Sep 2010 08:57:46 +0700 Subject: Another paper on invokedynamic In-Reply-To: <4CA0AA6E.6050705@univ-mlv.fr> References: <1285593600.27094.208.camel@macbook> <4CA0AA6E.6050705@univ-mlv.fr> Message-ID: Hi R?mi, On Mon, Sep 27, 2010 at 21:30, R?mi Forax wrote: > ?Le 27/09/2010 15:20, Christian Thalinger a ?crit : >> On Mon, 2010-09-27 at 19:52 +0700, Chanwit Kaewkasi wrote: >>> I hope you find it useful somehow and any feedback is very welcome! >>> >>> http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf >> Nice read. ?It would be very interesting why Monte Carlo behaves like >> that. ?Did you look closer at it? > > I've done the same kind of test, not on SciMark 2.0 but on DaCapo Glad to hear that you tried transforming DaCapo as well. How did you overcome the limitation that primitives must follow references: http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-July/001875.html or probably I missed somethings in the recent builds? > and without rewriting all primitive operators (BTW, I haven't understand > why you have re-written it manually). It's getting fully automatic for now ;-) > The results was far better but I suppose it's due to the fact that I haven't > woven operators. > > A remark, you don't need to store all method handles in an array, > the one you initialize in the static block of each class. > > Instead of having one boostrap by callsite you can factor them to have one > bootstrap by invocation bytecode. This looks interesting but it seems to be my limitation that I cannot fully understand you suggestions at the moment. Maybe I'll try what you said and be back to you later. Thanks a lot. -Chanwit From christian.thalinger at oracle.com Tue Sep 28 00:00:39 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Sep 2010 09:00:39 +0200 Subject: Another paper on invokedynamic In-Reply-To: References: <1285593600.27094.208.camel@macbook> Message-ID: <1285657239.27094.750.camel@macbook> On Tue, 2010-09-28 at 08:57 +0700, Chanwit Kaewkasi wrote: > Hi Christian, > > On Mon, Sep 27, 2010 at 20:20, Christian Thalinger > wrote: > > On Mon, 2010-09-27 at 19:52 +0700, Chanwit Kaewkasi wrote: > >> I hope you find it useful somehow and any feedback is very welcome! > >> > >> http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf > > > > Nice read. It would be very interesting why Monte Carlo behaves like > > that. Did you look closer at it? > > No, I haven't. If you have some a good trick to hunt this kind of > bottle necks, I am glad to hear about it. I'd start using -XX:+PrintCompilation -XX:+PrintInlining to see what gets compiled and what not, and why not. Maybe there are also deopts. We'll see. -- Christian From forax at univ-mlv.fr Tue Sep 28 01:00:45 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 28 Sep 2010 10:00:45 +0200 Subject: Another paper on invokedynamic In-Reply-To: References: <1285593600.27094.208.camel@macbook> <4CA0AA6E.6050705@univ-mlv.fr> Message-ID: <4CA1A0AD.9020600@univ-mlv.fr> Le 28/09/2010 03:57, Chanwit Kaewkasi a ?crit : > Hi R?mi, > > On Mon, Sep 27, 2010 at 21:30, R?mi Forax wrote: >> Le 27/09/2010 15:20, Christian Thalinger a ?crit : >>> On Mon, 2010-09-27 at 19:52 +0700, Chanwit Kaewkasi wrote: >>>> I hope you find it useful somehow and any feedback is very welcome! >>>> >>>> http://dl.dropbox.com/u/381580/vmil10_kaewkasi_revised.pdf >>> Nice read. It would be very interesting why Monte Carlo behaves like >>> that. Did you look closer at it? >> I've done the same kind of test, not on SciMark 2.0 but on DaCapo > Glad to hear that you tried transforming DaCapo as well. > How did you overcome the limitation that primitives must follow references: > > http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-July/001875.html > > or probably I missed somethings in the recent builds? I don't know for recent build. When I've tested the reference implementation (hotspot), I've disabled transformation if I detect a method type that will be not handled by the RI. Otherwise if you test DaCapo-jython there is no such problematic signature in it. I've initally develop the weaver as a non regression test for the backport, and with the backport there is no such problem. >> and without rewriting all primitive operators (BTW, I haven't understand >> why you have re-written it manually). > It's getting fully automatic for now ;-) > >> The results was far better but I suppose it's due to the fact that I haven't >> woven operators. >> >> A remark, you don't need to store all method handles in an array, >> the one you initialize in the static block of each class. >> >> Instead of having one boostrap by callsite you can factor them to have one >> bootstrap by invocation bytecode. > This looks interesting but it seems to be my limitation that I cannot > fully understand you suggestions at the moment. Maybe I'll try what > you said and be back to you later. Thanks a lot. You can have only 4 bootstrap methods, one by invoke* instruction > -Chanwit R?mi From forax at univ-mlv.fr Tue Sep 28 01:52:39 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 28 Sep 2010 10:52:39 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285613479.27094.576.camel@macbook> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285600805.27094.348.camel@macbook> <4CA0C656.3090207@univ-mlv.fr> <1285613479.27094.576.camel@macbook> Message-ID: <4CA1ACD7.5040709@univ-mlv.fr> Le 27/09/2010 20:51, Christian Thalinger a ?crit : > On Mon, 2010-09-27 at 18:29 +0200, R?mi Forax wrote: >> Le 27/09/2010 17:20, Christian Thalinger a ?crit : >>> On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: >>> >>>> On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: >>>> >>>>> Christian, you can also test with PHP.reboot >>>>> http://code.google.com/p/phpreboot/ >>>>> tests are here: >>>>> >>>>> http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test >>>>> >>>>> The runtime also provides an ahead of time compiler that generates >>>>> bytecode classes: >>>>> bin/phpr.sh -aot test/testfibo.phpr >>>>> >>>> Thanks for the hint, I'll give it a try. -- Christian >>>> >>> What about this one: >>> >> This one is my bug :) >> I've refactored the way to escape from a trace but don't update the code >> that reuse a trace. My bad. >> All inner-loops that contains at least an untaken branch will not work. > Alright :-) -- Christian Fixed :) R?mi From christian.thalinger at oracle.com Tue Sep 28 05:47:54 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Sep 2010 14:47:54 +0200 Subject: JavaOne meet-up? In-Reply-To: <4CA1ACD7.5040709@univ-mlv.fr> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285600805.27094.348.camel@macbook> <4CA0C656.3090207@univ-mlv.fr> <1285613479.27094.576.camel@macbook> <4CA1ACD7.5040709@univ-mlv.fr> Message-ID: <1285678074.27094.1108.camel@macbook> On Tue, 2010-09-28 at 10:52 +0200, R?mi Forax wrote: > Le 27/09/2010 20:51, Christian Thalinger a ?crit : > > On Mon, 2010-09-27 at 18:29 +0200, R?mi Forax wrote: > >> Le 27/09/2010 17:20, Christian Thalinger a ?crit : > >>> On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: > >>> > >>>> On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: > >>>> > >>>>> Christian, you can also test with PHP.reboot > >>>>> http://code.google.com/p/phpreboot/ > >>>>> tests are here: > >>>>> > >>>>> http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test > >>>>> > >>>>> The runtime also provides an ahead of time compiler that generates > >>>>> bytecode classes: > >>>>> bin/phpr.sh -aot test/testfibo.phpr > >>>>> > >>>> Thanks for the hint, I'll give it a try. -- Christian > >>>> > >>> What about this one: > >>> > >> This one is my bug :) > >> I've refactored the way to escape from a trace but don't update the code > >> that reuse a trace. My bad. > >> All inner-loops that contains at least an untaken branch will not work. > > Alright :-) -- Christian > > Fixed :) Thanks, it works. -- Christian From christian.thalinger at oracle.com Tue Sep 28 08:46:31 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Sep 2010 17:46:31 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285356284.15396.896.camel@macbook> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> Message-ID: <1285688791.27094.1317.camel@macbook> On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: > On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: > > Christian, you can also test with PHP.reboot > > http://code.google.com/p/phpreboot/ > > tests are here: > > > > http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test > > > > The runtime also provides an ahead of time compiler that generates > > bytecode classes: > > bin/phpr.sh -aot test/testfibo.phpr > > Thanks for the hint, I'll give it a try. -- Christian Is there a reason why all your libraries are on the boot-classpath? When I run test/testtracefun2.phpr and put the libraries on the system-classpath I get a segfault when verifying the signature of a DirectMethodHandle. Anyway, I think there is a bug somewhere. -- Christian From headius at headius.com Tue Sep 28 09:28:29 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 28 Sep 2010 11:28:29 -0500 Subject: Updated backport? Message-ID: It appears the current release of the backport, 1.3, could use a refresh. In addition, the jsr292-mock.jar was built with Java 7, which brings up a lot of compile-time errors when using it with non-Java 7 :) R?mi: Can you spin a build of jsr292-backport? - Charlie From forax at univ-mlv.fr Tue Sep 28 11:04:00 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 28 Sep 2010 20:04:00 +0200 Subject: JavaOne meet-up? In-Reply-To: <1285688791.27094.1317.camel@macbook> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285688791.27094.1317.camel@macbook> Message-ID: <4CA22E10.5060205@univ-mlv.fr> Le 28/09/2010 17:46, Christian Thalinger a ?crit : > On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: > >> On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: >> >>> Christian, you can also test with PHP.reboot >>> http://code.google.com/p/phpreboot/ >>> tests are here: >>> >>> http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test >>> >>> The runtime also provides an ahead of time compiler that generates >>> bytecode classes: >>> bin/phpr.sh -aot test/testfibo.phpr >>> >> Thanks for the hint, I'll give it a try. -- Christian >> > Is there a reason why all your libraries are on the boot-classpath? > > When I run test/testtracefun2.phpr and put the libraries on the > system-classpath I get a segfault when verifying the signature of a > DirectMethodHandle. > Two reasons. When I start the project, the RI was throwing a ClassNotFoundError if a class used in a signature of an invokedynamic was not loaded by the bootstrap classloader. Since John fixes that problem. The other reason is more dubious, put classes in bootclasspath avoid verification which speed up the start-up time. > Anyway, I think there is a bug somewhere. > > -- Christian > R?mi From christian.thalinger at oracle.com Tue Sep 28 11:11:47 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Sep 2010 20:11:47 +0200 Subject: JavaOne meet-up? In-Reply-To: <4CA22E10.5060205@univ-mlv.fr> References: <1285327001.15396.377.camel@macbook> <4C9CA640.4040909@univ-mlv.fr> <1285356284.15396.896.camel@macbook> <1285688791.27094.1317.camel@macbook> <4CA22E10.5060205@univ-mlv.fr> Message-ID: <1285697507.27094.1481.camel@macbook> On Tue, 2010-09-28 at 20:04 +0200, R?mi Forax wrote: > Le 28/09/2010 17:46, Christian Thalinger a ?crit : > > On Fri, 2010-09-24 at 21:24 +0200, Christian Thalinger wrote: > > > >> On Fri, 2010-09-24 at 15:23 +0200, R?mi Forax wrote: > >> > >>> Christian, you can also test with PHP.reboot > >>> http://code.google.com/p/phpreboot/ > >>> tests are here: > >>> > >>> http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/test > >>> > >>> The runtime also provides an ahead of time compiler that generates > >>> bytecode classes: > >>> bin/phpr.sh -aot test/testfibo.phpr > >>> > >> Thanks for the hint, I'll give it a try. -- Christian > >> > > Is there a reason why all your libraries are on the boot-classpath? > > > > When I run test/testtracefun2.phpr and put the libraries on the > > system-classpath I get a segfault when verifying the signature of a > > DirectMethodHandle. > > > > Two reasons. > When I start the project, the RI was throwing a ClassNotFoundError > if a class used in a signature of an invokedynamic > was not loaded by the bootstrap classloader. > Since John fixes that problem. I think a similar I'm hitting now, but this time the VM crashes. -- Christian From forax at univ-mlv.fr Tue Sep 28 13:05:57 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 28 Sep 2010 22:05:57 +0200 Subject: Updated backport? In-Reply-To: References: Message-ID: <4CA24AA5.8000607@univ-mlv.fr> Le 28/09/2010 18:28, Charles Oliver Nutter a ?crit : > It appears the current release of the backport, 1.3, could use a > refresh. In addition, the jsr292-mock.jar was built with Java 7, which > brings up a lot of compile-time errors when using it with non-Java 7 > :) > All mock jars that I've generated was 1.7 compatible, I don't see what is the problem. Anyway, I've done a resync which is 1.5 compatible. > R?mi: Can you spin a build of jsr292-backport? > done > - Charlie > R?mi From headius at headius.com Wed Sep 29 13:14:10 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 29 Sep 2010 15:14:10 -0500 Subject: JavaOne meet-up? In-Reply-To: <1285327001.15396.377.camel@macbook> References: <1285327001.15396.377.camel@macbook> Message-ID: On Fri, Sep 24, 2010 at 6:16 AM, Christian Thalinger wrote: > That sounds good. ?Any time-frame when you get to do it? ?I'd like to > use JRuby again as testing kit for our latest changes. I pushed changes to JRuby yesterday that allow it to compile and run against current indy stuff. Hopefully I can get back to using indy more heavily soon. - Charlie From christian.thalinger at oracle.com Wed Sep 29 13:21:59 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 29 Sep 2010 22:21:59 +0200 Subject: JavaOne meet-up? In-Reply-To: References: <1285327001.15396.377.camel@macbook> Message-ID: <1285791719.27094.2520.camel@macbook> On Wed, 2010-09-29 at 15:14 -0500, Charles Oliver Nutter wrote: > On Fri, Sep 24, 2010 at 6:16 AM, Christian Thalinger > wrote: > > That sounds good. Any time-frame when you get to do it? I'd like to > > use JRuby again as testing kit for our latest changes. > > I pushed changes to JRuby yesterday that allow it to compile and run > against current indy stuff. Hopefully I can get back to using indy > more heavily soon. Thanks for that! I can run the tests again and already found bugs ;-( -- Christian From john.r.rose at oracle.com Wed Sep 29 14:46:09 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 29 Sep 2010 21:46:09 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: add an N-ary version of the MethodApply feature Message-ID: <20100929214610.3AF6147D34@hg.openjdk.java.net> Changeset: 022c417e0094 Author: jrose Date: 2010-09-15 01:17 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/022c417e0094 meth: add an N-ary version of the MethodApply feature ! meth-bcon-6984311.patch + meth-bcon-nary.patch ! series From john.r.rose at oracle.com Wed Sep 29 15:48:10 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 29 Sep 2010 22:48:10 +0000 Subject: hg: mlvm/mlvm/jdk: meth-cval: update javadoc, add test for javadoc example Message-ID: <20100929224810.BA3C647D37@hg.openjdk.java.net> Changeset: 4c80d5b4cbff Author: jrose Date: 2010-09-29 15:47 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4c80d5b4cbff meth-cval: update javadoc, add test for javadoc example ! meth-cval-6982752.patch From per at bothner.com Wed Sep 29 17:00:06 2010 From: per at bothner.com (Per Bothner) Date: Wed, 29 Sep 2010 17:00:06 -0700 Subject: MethodHandles for Kawa and other functional languages? Message-ID: <4CA3D306.4000009@bothner.com> I'm interested into (at least) evaluating MethodHandles for Kawa (and similar languages with first-class functions). But I'm not quite sure where to start, or what is the right abstraction. Kawa's function implementation is fairly efficient. Calls to known functions compile to direct method calls. Calls to unknown methods call an "apply" method that does argument checking/conversion and then calls the method. The most obvious overhead which MethodHandles could fix is boxing followed by unboxing. It could also help when a Procedure is defined as a set of multiple "MethodProcs". Right now Procedure is an abstract class, with various implementations. Directly replacing Procedure by MethodHandle would probably be most efficient, but difficult. Note that Procedure may have properties (such as its name) Another alternative is to store the MethodHandle in the Procedure - i.e. Procedure is a wrapper around Methodhandle. However, I suspect that might not give the full performance benefit. I'm considering something like: public abstract class Procedure { MethodHandle mh; // initialized by sub-class public abstract MethodHandle asMethodHandle() { return mh; } } The default implementation of asMethodHandle just results something that calls Procedure's apply method. For example: /* 1-argument function */ public abstract class Procedure1 extends Procedure { Procedure1() { MethodType mt = MethodType.methodType(Object.class, Object.class); return MethodHandles.lookup().findVirtual(getClass(), "apply1", mt); } public abstract Object apply1 (Object arg1); } A Procedure that corresponds to a user-written procedure could have a specialized MethodType that points directly to the implementation method. When you call an unknwon procedure, you would first call asMethodHandle() before calling invoke on the MethodHandle. (If the same Procedure variable is called multiple times (like in a loop) it makes sense to call asMethodHandle() once. If there was a way to associate properties with a MethodHandle then the runtime could use MethodHandles directly, since Kawa could always get the Procedure back from the MethodHandle. But that assumes that (some) MethodHandles have identity. Fundamentally, the question is: When the Scheme programmer passes of function to a higher-level function (like map), what is the type of the object passed: A MethodHandle? A Procedure? Something else? There seem to be different kind of MethodHandles, so perhaps something is appropriate. Is there some blog article or cookbook discussing this? -- --Per Bothner per at bothner.com http://per.bothner.com/ From john.r.rose at oracle.com Wed Sep 29 18:08:59 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 29 Sep 2010 18:08:59 -0700 Subject: MethodHandles for Kawa and other functional languages? In-Reply-To: <4CA3D306.4000009@bothner.com> References: <4CA3D306.4000009@bothner.com> Message-ID: On Sep 29, 2010, at 5:00 PM, Per Bothner wrote: > Fundamentally, the question is: When the Scheme programmer passes > of function to a higher-level function (like map), what is the type > of the object passed: A MethodHandle? A Procedure? Something else? > There seem to be different kind of MethodHandles, so perhaps something > is appropriate. Is there some blog article or cookbook discussing this? Quick answer to your next-to-last question: The language-specific APIs should use their own interfaces or classes, so continue to use Procedure. But if and when you go to JSR 292 API's you need to convert to the MH type. The MethodHandleProvider (aka MethodHandleBox) interface is supposed to make this process more regular. For example, an invokedynamic bootstrap method (binding a Scheme call site) needs to return either a CallSite wrapped around a method handle (if it is to be rebindable) or a MethodHandle (if not). In either case, you'll want to convert your Procedure down to a MH when binding it to an invokedynamic call site. Your internal field Procedure.mh field might be made lazy or even virtualized away, as long as MHP.asMethodHandle does something reasonable for every individual Procedure. It depends on how or whether you want to use polymorphism in the Procedure type, or whether you want to do all the polymorphism through method handles. At a minimum, you'll want to make out-calls to random Java methods through method handles, instead of through reflection or thousands of inner classes. By the way, the usefulness (or not) of MHP is a matter of debate on the JSR 292 EG, so I'm eager for insights. Also, I will read your message over in more detail. -- John From alessiostalla at gmail.com Thu Sep 30 00:44:39 2010 From: alessiostalla at gmail.com (Alessio Stalla) Date: Thu, 30 Sep 2010 09:44:39 +0200 Subject: MethodHandles for Kawa and other functional languages? In-Reply-To: References: <4CA3D306.4000009@bothner.com> Message-ID: On Thu, Sep 30, 2010 at 3:08 AM, John Rose wrote: > On Sep 29, 2010, at 5:00 PM, Per Bothner wrote: > >> Fundamentally, the question is: When the Scheme programmer passes >> of function to a higher-level function (like map), what is the type >> of the object passed: A MethodHandle? ?A Procedure? ?Something else? >> There seem to be different kind of MethodHandles, so perhaps something >> is appropriate. ?Is there some blog article or cookbook discussing this? > > Quick answer to your next-to-last question: ?The language-specific APIs should use their own interfaces or classes, so continue to use Procedure. ?But if and when you go to JSR 292 API's you need to convert to the MH type. ?The MethodHandleProvider (aka MethodHandleBox) interface is supposed to make this process more regular. > > For example, an invokedynamic bootstrap method (binding a Scheme call site) needs to return either a CallSite wrapped around a method handle (if it is to be rebindable) or a MethodHandle (if not). ?In either case, you'll want to convert your Procedure down to a MH when binding it to an invokedynamic call site. > > Your internal field Procedure.mh field might be made lazy or even virtualized away, as long as MHP.asMethodHandle does something reasonable for every individual Procedure. ?It depends on how or whether you want to use polymorphism in the Procedure type, or whether you want to do all the polymorphism through method handles. ?At a minim u m, you'll want to make out-calls to random Java methods through method handles, instead of through reflection or thousands of inner classes. > > By the way, the usefulness (or not) of MHP is a matter of debate on the JSR 292 EG, so I'm eager for insights. > > Also, I will read your message over in more detail. This is interesting, because I'm starting to evaluate JSR 292 in ABCL, another JVM Lisp implementation (Common Lisp), and I'm pretty much following John's advice already (I didn't know about MHP, so I implemented my own Function.asMethodHandle). Now ABCL compiles function calls - say (foo ...) - to something like _theSymbolFoo.getSymbolFunctionOrDie().execute(...) where _theSymbolFoo is a static field referring to the first-class symbol object 'FOO and getSymbolFunctionOrDie() returns the function associated with that symbol, or signals an error if the symbol has no associated function. Functions are instances of ABCL's class Function. My plan for bringing invokedynamic into that picture is to compile function calls to (bytecode equivalent to): InvokeDynamic.#"SOME-LISP-PACKAGE:FOO"(...) and in the bootstrap method, roughly, ... Symbol sym = readFromString(methodName); MethodHandle mh = sym.getSymbolFunctionOrDie().asMethodHandle(); ... Then, to handle redefinition of functions, I'll store call sites into a list for each symbol (say, callSites), and have Symbol.setSymbolFunction(Function fun) { synchronized(callSites) { for(CallSite c : callSites) { c.setTarget(fun.asMethodHandle()); } this.function = fun; } } Actually in my sketch implementation (yet to be integrated into the compiler), callSites is a Set backed by a WeakHashMap. But I'm not sure whether the weakness is actually required. This way function lookup should be done only once, at linking time (and at redefinition time), and all subsequent calls will be direct method calls. Regards, Alessio Stalla From eller.helmut at gmail.com Thu Sep 30 03:48:38 2010 From: eller.helmut at gmail.com (Helmut Eller) Date: Thu, 30 Sep 2010 12:48:38 +0200 Subject: MethodHandles for Kawa and other functional languages? References: <4CA3D306.4000009@bothner.com> Message-ID: * Alessio Stalla [2010-09-30 07:44] writes: > InvokeDynamic.#"SOME-LISP-PACKAGE:FOO"(...) > > and in the bootstrap method, roughly, > > ... > Symbol sym = readFromString(methodName); > MethodHandle mh = sym.getSymbolFunctionOrDie().asMethodHandle(); > ... Just out of curiosity: what do you do if the package was renamed (say from SOME-LISP-PACKAGE to ANOTHER-LISP-PACKAGE) before the bootstrap method gets executed? Helmut From alessiostalla at gmail.com Thu Sep 30 04:52:38 2010 From: alessiostalla at gmail.com (Alessio Stalla) Date: Thu, 30 Sep 2010 13:52:38 +0200 Subject: MethodHandles for Kawa and other functional languages? In-Reply-To: References: <4CA3D306.4000009@bothner.com> Message-ID: On Thu, Sep 30, 2010 at 12:48 PM, Helmut Eller wrote: > * Alessio Stalla [2010-09-30 07:44] writes: > >> InvokeDynamic.#"SOME-LISP-PACKAGE:FOO"(...) >> >> and in the bootstrap method, roughly, >> >> ... >> Symbol sym = readFromString(methodName); >> MethodHandle mh = sym.getSymbolFunctionOrDie().asMethodHandle(); >> ... > > Just out of curiosity: what do you do if the package was renamed (say > from SOME-LISP-PACKAGE to ANOTHER-LISP-PACKAGE) before the bootstrap > method gets executed? It'll fail miserably :D I hadn't thought about that case, thanks for pointing it out. The symbol should be available as a static field of the caller function, so I should be able to get at it through reflection: the name of the invoked method will then be the name of that field. Cheers, Alessio From eller.helmut at gmail.com Thu Sep 30 06:11:50 2010 From: eller.helmut at gmail.com (Helmut Eller) Date: Thu, 30 Sep 2010 15:11:50 +0200 Subject: MethodHandles for Kawa and other functional languages? References: <4CA3D306.4000009@bothner.com> Message-ID: * Alessio Stalla [2010-09-30 11:52] writes: > On Thu, Sep 30, 2010 at 12:48 PM, Helmut Eller wrote: >> >> Just out of curiosity: what do you do if the package was renamed (say >> from SOME-LISP-PACKAGE to ANOTHER-LISP-PACKAGE) before the bootstrap >> method gets executed? > > It'll fail miserably :D I hadn't thought about that case, thanks for > pointing it out. The symbol should be available as a static field of > the caller function, so I should be able to get at it through > reflection: the name of the invoked method will then be the name of > that field. Indeed, that should work. Very clever. I'm glad I asked you :-). I guess you could avoid reflection if you generate a custom bootstrap method for each callsite. Hmm.. probably just as clumsy as reflection. Helmut From alessiostalla at gmail.com Thu Sep 30 06:28:20 2010 From: alessiostalla at gmail.com (Alessio Stalla) Date: Thu, 30 Sep 2010 15:28:20 +0200 Subject: MethodHandles for Kawa and other functional languages? In-Reply-To: References: <4CA3D306.4000009@bothner.com> Message-ID: On Thu, Sep 30, 2010 at 3:11 PM, Helmut Eller wrote: > * Alessio Stalla [2010-09-30 11:52] writes: > >> On Thu, Sep 30, 2010 at 12:48 PM, Helmut Eller ?wrote: >>> >>> Just out of curiosity: what do you do if the package was renamed (say >>> from SOME-LISP-PACKAGE to ANOTHER-LISP-PACKAGE) before the bootstrap >>> method gets executed? >> >> It'll fail miserably :D I hadn't thought about that case, thanks for >> pointing it out. The symbol should be available as a static field of >> the caller function, so I should be able to get at it through >> reflection: the name of the invoked method will then be the name of >> that field. > > Indeed, that should work. ?Very clever. ?I'm glad I asked you :-). :) > I guess you could avoid reflection if you generate a custom bootstrap > method for each callsite. ?Hmm.. probably just as clumsy as reflection. Yeah, clumsy and suffering from code bloat - I'm already disturbed to have one static block registering the bootstrap method for each class (i.e. per compiled function). I'd have much preferred if bootstrap method registration were inheritable. But that aside, after all reflection will only be used the very first time the callsite is linked, so it shouldn't be much of a problem. From eller.helmut at gmail.com Thu Sep 30 07:03:10 2010 From: eller.helmut at gmail.com (Helmut Eller) Date: Thu, 30 Sep 2010 16:03:10 +0200 Subject: MethodHandles for Kawa and other functional languages? References: <4CA3D306.4000009@bothner.com> Message-ID: * Alessio Stalla [2010-09-30 13:28] writes: >> I guess you could avoid reflection if you generate a custom bootstrap >> method for each callsite. ?Hmm.. probably just as clumsy as reflection. > > Yeah, clumsy and suffering from code bloat - I'm already disturbed to > have one static block registering the bootstrap method I think with the new fancy constants you can put the bootstrap method(handle) in the constant pool and the invokedynamic instruction refers to the constant pool; no registering required. > for each class (i.e. per compiled function). I'd have much preferred > if bootstrap method registration were inheritable. Can't you put many lisp functions in one class file? At least for non-closure functions that seems possible. > But that aside, after all > reflection will only be used the very first time the callsite is > linked, so it shouldn't be much of a problem. Reflection is never cheap, at least according to folk wisdom. Helmut From alessiostalla at gmail.com Thu Sep 30 07:20:05 2010 From: alessiostalla at gmail.com (Alessio Stalla) Date: Thu, 30 Sep 2010 16:20:05 +0200 Subject: MethodHandles for Kawa and other functional languages? In-Reply-To: References: <4CA3D306.4000009@bothner.com> Message-ID: On Thu, Sep 30, 2010 at 4:03 PM, Helmut Eller wrote: > * Alessio Stalla [2010-09-30 13:28] writes: > >>> I guess you could avoid reflection if you generate a custom bootstrap >>> method for each callsite. ?Hmm.. probably just as clumsy as reflection. >> >> Yeah, clumsy and suffering from code bloat - I'm already disturbed to >> have one static block registering the bootstrap method > > I think with the new fancy constants you can put the bootstrap > method(handle) in the constant pool and the invokedynamic instruction > refers to the constant pool; no registering required. Ok, interesting, I wasn't aware of that. >> for each class (i.e. per compiled function). ?I'd have much preferred >> if bootstrap method registration were inheritable. > > Can't you put many lisp functions in one class file? ?At least for > non-closure functions that seems possible. It is possible, and it's something we eventually want to support, but currently we have strictly one class file per function (though local non-closure functions are inlined when possible). Less than one class per top-level function is probably not worth the effort though, imho. >> But that aside, after all >> reflection will only be used the very first time the callsite is >> linked, so it shouldn't be much of a problem. > > Reflection is never cheap, at least according to folk wisdom. It's not cheap, especially the first time you reflectively access a given member like in my case, but consider that until some time ago all our functions were loaded from FASLs by using reflection, and that we use autoload a lot, so a little extra cost for every time a call site is first linked does not seem too bad. Of course part of the reason I'm doing this prototype is to find out whether invokedynamic is really beneficial or not for us. Alessio From christian.thalinger at oracle.com Thu Sep 30 10:50:52 2010 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 30 Sep 2010 19:50:52 +0200 Subject: Flag EnableInvokeDynamic hurt performance ? In-Reply-To: <4C9E5CC8.2000308@univ-mlv.fr> References: <4C9E3C48.4010607@univ-mlv.fr> <4C9E3F4B.3070200@univ-mlv.fr> <4C9E4348.2070006@univ-mlv.fr> <4C9E5CC8.2000308@univ-mlv.fr> Message-ID: <1285869052.1772.343.camel@macbook> On Sat, 2010-09-25 at 22:34 +0200, R?mi Forax wrote: > Le 25/09/2010 22:03, John Rose a ?crit : > > On Sep 25, 2010, at 11:45 AM, R?mi Forax wrote: > > > > > >> John, Christian, is it fixable ? > >> > > Yes. We're talking about fixing this, soon, as part of 6817525. > > > > -- John > > > > Cool. Today I started working on 6817525. -- Christian