From lukas.stadler at jku.at Thu Apr 1 08:38:31 2010 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Thu, 01 Apr 2010 15:38:31 +0000 Subject: hg: mlvm/mlvm/jdk: coroutine api simplification Message-ID: <20100401153832.95D7C44CE7@hg.openjdk.java.net> Changeset: 98e0f1ac4b42 Author: LS at polonius.ssw.uni-linz.ac.at Date: 2010-04-01 17:37 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/98e0f1ac4b42 coroutine api simplification ! coro.patch From lukas.stadler at jku.at Thu Apr 1 08:40:02 2010 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Thu, 01 Apr 2010 15:40:02 +0000 Subject: hg: mlvm/mlvm/hotspot: coroutine api simplification Message-ID: <20100401154003.8388644CE8@hg.openjdk.java.net> Changeset: 868956c9fe9e Author: lstadler Date: 2010-04-01 17:39 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/868956c9fe9e coroutine api simplification ! coro.patch From Christian.Thalinger at Sun.COM Fri Apr 2 05:56:11 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Fri, 02 Apr 2010 12:56:11 +0000 Subject: hg: mlvm/mlvm/hotspot: fix-oop-relocs-6940520: New patch. Message-ID: <20100402125612.C1C3044E27@hg.openjdk.java.net> Changeset: 90fe8277ed0f Author: twisti Date: 2010-04-02 14:55 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/90fe8277ed0f fix-oop-relocs-6940520: New patch. + fix-oop-relocs-6940520.patch ! series From szegedia at gmail.com Fri Apr 2 09:34:33 2010 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 2 Apr 2010 18:34:33 +0200 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: <2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com> Message-ID: <412E2261-717A-4EC6-9975-CF0D46EFDA61@gmail.com> On 2010.03.25., at 20:32, Charles Oliver Nutter wrote: > On Thu, Mar 25, 2010 at 1:14 PM, John Rose wrote: >>> MethodHandleImpl.java:1104:in `raiseException': >>> java.lang.ClassCastException: required class [Ljava.lang.Object; but >>> encountered class java.util.Collections$UnmodifiableRandomAccessList >>> from MethodHandle.java:357:in `invokeVarargs' >>> from MethodHandles.java:563:in `invoke' >>> from DynamicLinkerImpl.java:120:in `_relinkAndInvoke' >>> from FilterGeneric.java:520:in `invoke_C0' >>> from dynamic.duby:3:in `foo' >>> ... >> >> Do you know who is creating the UnmodifiableRandomAccessList? >> >> It looks like it needs a toArray call to create the low-level varargs list. > > I don't think it does. The URAL comes from Duby's literal array syntax > (the [1,2,3] in the example) and for the error in question it's simply > the receiver of the call (getClass or size). For the record, with my own MLVM build from last August, I have 6 unit test errors - all in the TestSimpleDynamicMethod.testVarArgs*() testcases; they're known issues in that version of MethodHandles support, with int[] -> Object[] conversion for varargs. With Stephen Bannasch's java-1.7.0-internal-2010_03_07.tar.gz, I'm getting those 6 (so they're *still* not fixed...), *and* I'm getting 12 new ones that previously worked, mostly all similar to the ClassCastException you reported, i.e. here's one from a really simple testcase, the "test fixed name property getter" - doesn't get much simpler than that :-): java.lang.ClassCastException: required class [Ljava.lang.Object; but encountered class org.dynalang.dynalink.beans.TestPropertyGetter$T1 at sun.dyn.MethodHandleImpl.raiseException(MethodHandleImpl.java:1104) at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:357) at java.dyn.MethodHandles.invoke(MethodHandles.java:563) at org.dynalang.dynalink.support.DynamicLinkerImpl._relinkAndInvoke(DynamicLinkerImpl.java:120) at sun.dyn.FilterGeneric$F1.invoke_C0(FilterGeneric.java:520) at sun.dyn.FilterGeneric$F1.invoke_F0(FilterGeneric.java:514) at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:357) at java.dyn.MethodHandles.invoke(MethodHandles.java:563) at org.dynalang.dynalink.beans.TestPropertyGetter.testFixedNamePropertyGetter(TestPropertyGetter.java:26) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:613) at junit.framework.TestCase.runTest(TestCase.java:164) ... I'll investigate, but I'm afraid the problem is in the JRE. In the next step, I think I'll update my own local Mercurial copy, apply the patches, and do a build myself - so at least I have source xref to the stack traces. John, can you maybe enlighten us as to why does java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:357) expect the first argument to be an Object[] - it should be arbitrarily typed receiver, no? Thanks, Attila. -- home: http://www.szegedi.org twitter: http://twitter.com/szegedi weblog: http://constc.blogspot.com From szegedia at gmail.com Fri Apr 2 10:20:46 2010 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 2 Apr 2010 19:20:46 +0200 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: <2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com> <032AC890-C37A-487F-93AF-EFCB67CE2782@gmail.com> Message-ID: On 2010.03.25., at 20:25, Charles Oliver Nutter wrote: > On Thu, Mar 25, 2010 at 12:56 PM, Attila Szegedi wrote: >> I did give tips for usage in DynamicLinker javadoc; the simplest you can get is: >> >> public class MyLanguageRuntime { >> private static final DynamicLinker dynamicLinker = new DynamicLinkerFactory().createLinker(); >> >> public static CallSite bootstrap(Object caller, String name, MethodType type) { >> RelinkableCallSite callSite = new MonomorphicCallSite(caller, name, type); >> dynamicLinker.link(callSite); >> return callSite; >> } >> } >> >> and then every class just does: >> >> public class MyClass { >> static { >> Linkage.registerBootstrapMethod(MyLanguageRuntime.class, "bootstrap"); >> } >> ... >> } > > Yep, that's exactly what I wanted. But I think it would be nice to > have a JavaLanguageLinker built-in so that I don't have to maintain > *any* Java code of my own. This is literally all I need, and I don't > think I'll be alone. Well, I *could* add a convenience "DefaultBootstrapper". My only problem with it is that it is a singleton, and there is actually some hidden state at play here, the two together are synonymous with "tricky trap" :-). Namely "new DynamicLinkerFactory().createLinker()" won't just give you a POJO linker, but a composite linker assembled from all linkers that can be automatically discovered via the java.util.ServiceLoader in the classpath of the current thread's context class loader. A linker is always tied to a class loader, and there's some other uses for that class loader in the library, namely it'll dare store strong references to classes visible through the loader it's associated with, but only weak references to classes not visible through it (to prevent accidental cross-loader retaining of classes). I really don't like singletons, and try to not have them in the libraries I write :-) >>> P.S. Switch to git :) >> >> I will; I certainly have the intent. I do have an account on github, I created it to fork Syrinx last year to integrate it with MOP :-) I'm still learning it (Git, that is). As I lamented elsewhere: first I encountered CVS[*]. By the time I mastered CVS, Subversion comes along. By the time I decently learned Subversion, I need Mercurial (for MLVM). By the time I grasp enough Mercurial to check out OpenJDK and apply MLVM patches, cool kids go Git. It's hard keeping up with the version control system fashion... :-) >> >> What (if any) IDE integration do you use with Git? > > I've used CVS, SVN, SS, Hg, Git, Perforce (a little) and Clearcase (a > little). Git has just about the worst learning curve for cli > interaction, but it's structured better than any other I've used. > > IDE support, unfortunately, lags enough that I don't use it. I have > use the nbgit plugin, which is pretty good. I'm pretty sure IDEA has > great integration as usual, and I've heard Eclipse is pretty good. I > just use command-line, raw git. I started the preparations to migrate to git, but I'll now instead spend time on building a MLVM on my own from latest sources and see whether I still get the testcase errors. Long-term plan is to definitely move to git. Attila. > > - Charlie From szegedia at gmail.com Fri Apr 2 13:41:01 2010 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 2 Apr 2010 22:41:01 +0200 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: <2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com> <032AC890-C37A-487F-93AF-EFCB67CE2782@gmail.com> Message-ID: On 2010.04.02., at 19:20, Attila Szegedi wrote: > I started the preparations to migrate to git, but I'll now instead spend time on building a MLVM on my own from latest sources and see whether I still get the testcase errors. Long-term plan is to definitely move to git. Folks, I wasn't able to rebuild MLVM on my own. The obvious difference is that I'm now on Snow Leopard... I was trying with my own build.sh that worked back on Leopard, but I got errors in the c++ compiler first. Solved those by using the ALT_COMPILER_PATH trick to force the build to use GCC 4.0.1 instead of 4.2.1. Next I got errors in the linker (ld). Don't have the exact error anymore, unfortunately... So I decided to throw in the towel, and use Stephen Bannasch's excellent "update.sh" from It now bombs with: /Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/opto/runtime.cpp: In static member function 'static u_char* OptoRuntime::rethrow_C(oopDesc*, JavaThread*, u_char*)': /Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/opto/runtime.cpp:955: error: no matching function for call to 'SharedRuntime::raw_exception_handler_for_return_address(JavaThread*&, u_char*&)' /Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/runtime/sharedRuntime.hpp:101: note: candidates are: static u_char* SharedRuntime::raw_exception_handler_for_return_address(u_char*) make[6]: *** [runtime.o] Error 1 make[6]: *** Waiting for unfinished jobs.... make[5]: *** [the_vm] Error 2 make[4]: *** [product] Error 2 make[3]: *** [generic_build2] Error 2 make[2]: *** [product] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2 Digging backwards I can see this: + (cd sources/hotspot; hg qpush -a) abort: local changes found, refresh first *** Exit status 255. Does this mean that the current MLVM hotspot patches can't be applied to the tip of the bsd-port/hotspot? (Or am I doing something wrong?) Attila. > Attila. From szegedia at gmail.com Fri Apr 2 14:36:39 2010 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 2 Apr 2010 23:36:39 +0200 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: Message-ID: On 2010.03.25., at 3:17, Charles Oliver Nutter wrote: > For Attila: I had to remove a spreadArguments handle you used for > re-binding the method...not sure why. Here's the diff: Turns out, now the MethodHandle.invokeVarargs() actually does the whole convert-to-generic-and-invoke-as-vararg, so I committed the definitive solution for it now, which is simply: Index: DynamicLinkerImpl.java =================================================================== --- DynamicLinkerImpl.java (revision 233) +++ DynamicLinkerImpl.java (revision 228) @@ -111,6 +111,12 @@ // Invoke the method. Note we bypass the guard, as the assumption is // that the current arguments will pass the guard (and there actually // might be no guard at all). - return guardedInvocation.getInvocation().invokeVarargs(arguments); + final MethodHandle invocation = guardedInvocation.getInvocation(); + final MethodType genericType = invocation.type().generic(); + final MethodHandle genericizedInvocation = + MethodHandles.convertArguments(invocation, genericType); + final MethodHandle spreadInvocation = MethodHandles.spreadArguments( + genericizedInvocation, SPREAD_GENERIC_INVOCATION); + return MethodHandles.invoke(spreadInvocation, arguments); } } (Mind you, this is a reverse diff, but I'm too sleepy now to fix it; just swap + and -) I think the problem was in the fact that the (now deprecated) MethodHandles.invoke() used to behave as "invokeExact" in the last August's builds (so that's why I had to genericize + spread explicitly), while now it maps to MethodHandle.invokeVarargs(), so in addition to it being deprecated, its behaviour was also changed in the past half a year and that broke things, as you have yourself experienced :-). Should be good now. BTW, Stephen Bannasch's MLVM build works completely okay - I abandoned the attempt to now build my own as it didn't work out quickly and I didn't want to waste a lot of time; his version + Java sources from Mercurial seem sufficient for debugging. I'm still not back to the old 6 unit test errors, but this patch reduced them from 18 to 8; seems there are still two genuine new issues. Attila. > > Index: src/org/dynalang/dynalink/support/DynamicLinkerImpl.java > =================================================================== > --- src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (revision 232) > +++ src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (working copy) > @@ -115,8 +115,6 @@ > final MethodType genericType = invocation.type().generic(); > final MethodHandle genericizedInvocation = > MethodHandles.convertArguments(invocation, genericType); > - final MethodHandle spreadInvocation = MethodHandles.spreadArguments( > - genericizedInvocation, SPREAD_GENERIC_INVOCATION); > - return MethodHandles.invoke(spreadInvocation, arguments); > + return MethodHandles.invoke(genericizedInvocation, arguments); > } > } > > I committed a built version with this hack...no tests, etc yet for > Duby's "dynamic" type, but that will come soon. > > BTW, what's the current state of the art for emitting .java with an > invokedynamic in it? Duby also has a .java backend, so I'll need to > add indy support there as well (somehow). > > - Charlie From headius at headius.com Fri Apr 2 15:23:22 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 2 Apr 2010 17:23:22 -0500 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: Message-ID: On Fri, Apr 2, 2010 at 4:36 PM, Attila Szegedi wrote: > Turns out, now the MethodHandle.invokeVarargs() actually does the whole convert-to-generic-and-invoke-as-vararg, so I committed the definitive solution for it now, which is simply: Excellent! I updated the copy in Duby's repository, and it works now without my patch: ~/projects/duby ? CLASSPATH=javalib/dynalang-invoke-0.1.jar:src/ JAVA_OPTS="-XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic" bin/duby -e "def foo(a:dynamic); puts a.size; end; foo([1,2,3,4])" 4 Hopefully I can return to Duby work and MLVM playing in the near term. - Charlie From stephen.bannasch at deanbrook.org Sun Apr 4 19:56:12 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 4 Apr 2010 22:56:12 -0400 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: <2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com> <032AC890-C37A-487F-93AF-EFCB67CE2782@gmail.com> Message-ID: At 10:41 PM +0200 4/2/10, Attila Szegedi wrote: >So I decided to throw in the towel, and use Stephen Bannasch's excellent "update.sh" from > >It now bombs with: > >/Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/opto/runtime.cpp: In static member function 'static u_char* OptoRuntime::rethrow_C(oopDesc*, JavaThread*, u_char*)': >/Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/opto/runtime.cpp:955: error: no matching function for call to 'SharedRuntime::raw_exception_handler_for_return_address(JavaThread*&, u_char*&)' >/Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/runtime/sharedRuntime.hpp:101: note: candidates are: static u_char* SharedRuntime::raw_exception_handler_for_return_address(u_char*) >make[6]: *** [runtime.o] Error 1 >make[6]: *** Waiting for unfinished jobs.... >make[5]: *** [the_vm] Error 2 >make[4]: *** [product] Error 2 >make[3]: *** [generic_build2] Error 2 >make[2]: *** [product] Error 2 >make[1]: *** [hotspot-build] Error 2 >make: *** [build_product_image] Error 2 > >Digging backwards I can see this: > >+ (cd sources/hotspot; hg qpush -a) >abort: local changes found, refresh first >*** Exit status 255. > >Does this mean that the current MLVM hotspot patches can't be applied to the tip of the bsd-port/hotspot? >(Or am I doing something wrong?) Hi Attila, I've had that problem in the past. I think if I took the time to understand hg better the issue would be pretty clear. I solvedthe problem by recreating my local source repo (and added the instructions for doing this as comments in update.sh). Since then I have not had any errors where I couldn't update because of local changes. There have been times when the bsd-port code hasn't built properly for a while on 10.5 but that isn't the case now. I just built the latest bsd-port w/mlvm patches and it seems to work. I've uploaded a copy here: http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_04_04.tar.gz From john.r.rose at oracle.com Mon Apr 5 11:00:46 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 5 Apr 2010 11:00:46 -0700 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: <2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com> <032AC890-C37A-487F-93AF-EFCB67CE2782@gmail.com> Message-ID: FTR, there's a good smoke test for the method handles part of JSR 292 in the JDK sources: davinci/sources/jdk/test/java/dyn/MethodHandlesTest.java Running the test requires JUnit 4.5. $JSR292_JAVA_HOME/bin/java -ea -esa -XX:+{UnlockExperimentalVMOptions,EnableMethodHandles} -Xbootclasspath/a:$HOME/env/jars/junit-4.5.jar org.junit.runner.JUnitCore test.java.dyn.MethodHandlesTest The source file shows a number of known failures currently excluded from the test suite. (But the exclusions are decreasing over time!) The latest patch push (including meth-ing-6939134.patch) upgrades this test, and passes it cleanly. -- John On Apr 4, 2010, at 7:56 PM, Stephen Bannasch wrote: > At 10:41 PM +0200 4/2/10, Attila Szegedi wrote: >> So I decided to throw in the towel, and use Stephen Bannasch's excellent "update.sh" from >> >> It now bombs with: >> >> /Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/opto/runtime.cpp: In static member function 'static u_char* OptoRuntime::rethrow_C(oopDesc*, JavaThread*, u_char*)': >> /Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/opto/runtime.cpp:955: error: no matching function for call to 'SharedRuntime::raw_exception_handler_for_return_address(JavaThread*&, u_char*&)' >> /Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/runtime/sharedRuntime.hpp:101: note: candidates are: static u_char* SharedRuntime::raw_exception_handler_for_return_address(u_char*) >> make[6]: *** [runtime.o] Error 1 >> make[6]: *** Waiting for unfinished jobs.... >> make[5]: *** [the_vm] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** [generic_build2] Error 2 >> make[2]: *** [product] Error 2 >> make[1]: *** [hotspot-build] Error 2 >> make: *** [build_product_image] Error 2 >> >> Digging backwards I can see this: >> >> + (cd sources/hotspot; hg qpush -a) >> abort: local changes found, refresh first >> *** Exit status 255. >> >> Does this mean that the current MLVM hotspot patches can't be applied to the tip of the bsd-port/hotspot? >> (Or am I doing something wrong?) > > Hi Attila, > > I've had that problem in the past. I think if I took the time to understand hg better the issue would be pretty clear. I solvedthe problem by recreating my local source repo (and added the instructions for doing this as comments in update.sh). Since then I have not had any errors where I couldn't update because of local changes. > > There have been times when the bsd-port code hasn't built properly for a while on 10.5 but that isn't the case now. > > I just built the latest bsd-port w/mlvm patches and it seems to work. > > I've uploaded a copy here: > http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_04_04.tar.gz > > _______________________________________________ > 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 Apr 5 16:16:56 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 5 Apr 2010 16:16:56 -0700 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: Message-ID: <82A7A393-56FB-4A1B-9460-CF48D27CA5FF@oracle.com> The sources are changing rapidly at this point; I'm working on invokeGeneric. If you send me a JAR which which can run stand-alone, I can use it as a regression test. -- John On Apr 2, 2010, at 2:36 PM, Attila Szegedi wrote: > On 2010.03.25., at 3:17, Charles Oliver Nutter wrote: > >> For Attila: I had to remove a spreadArguments handle you used for >> re-binding the method...not sure why. Here's the diff: > > Turns out, now the MethodHandle.invokeVarargs() actually does the whole convert-to-generic-and-invoke-as-vararg, so I committed the definitive solution for it now, which is simply: > > Index: DynamicLinkerImpl.java > =================================================================== > --- DynamicLinkerImpl.java (revision 233) > +++ DynamicLinkerImpl.java (revision 228) > @@ -111,6 +111,12 @@ > // Invoke the method. Note we bypass the guard, as the assumption is > // that the current arguments will pass the guard (and there actually > // might be no guard at all). > - return guardedInvocation.getInvocation().invokeVarargs(arguments); > + final MethodHandle invocation = guardedInvocation.getInvocation(); > + final MethodType genericType = invocation.type().generic(); > + final MethodHandle genericizedInvocation = > + MethodHandles.convertArguments(invocation, genericType); > + final MethodHandle spreadInvocation = MethodHandles.spreadArguments( > + genericizedInvocation, SPREAD_GENERIC_INVOCATION); > + return MethodHandles.invoke(spreadInvocation, arguments); > } > } > > (Mind you, this is a reverse diff, but I'm too sleepy now to fix it; just swap + and -) > > I think the problem was in the fact that the (now deprecated) MethodHandles.invoke() used to behave as "invokeExact" in the last August's builds (so that's why I had to genericize + spread explicitly), while now it maps to MethodHandle.invokeVarargs(), so in addition to it being deprecated, its behaviour was also changed in the past half a year and that broke things, as you have yourself experienced :-). > > Should be good now. > > BTW, Stephen Bannasch's MLVM build works completely okay - I abandoned the attempt to now build my own as it didn't work out quickly and I didn't want to waste a lot of time; his version + Java sources from Mercurial seem sufficient for debugging. > > I'm still not back to the old 6 unit test errors, but this patch reduced them from 18 to 8; seems there are still two genuine new issues. > > Attila. > >> >> Index: src/org/dynalang/dynalink/support/DynamicLinkerImpl.java >> =================================================================== >> --- src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (revision 232) >> +++ src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (working copy) >> @@ -115,8 +115,6 @@ >> final MethodType genericType = invocation.type().generic(); >> final MethodHandle genericizedInvocation = >> MethodHandles.convertArguments(invocation, genericType); >> - final MethodHandle spreadInvocation = MethodHandles.spreadArguments( >> - genericizedInvocation, SPREAD_GENERIC_INVOCATION); >> - return MethodHandles.invoke(spreadInvocation, arguments); >> + return MethodHandles.invoke(genericizedInvocation, arguments); >> } >> } >> >> I committed a built version with this hack...no tests, etc yet for >> Duby's "dynamic" type, but that will come soon. >> >> BTW, what's the current state of the art for emitting .java with an >> invokedynamic in it? Duby also has a .java backend, so I'll need to >> add indy support there as well (somehow). >> >> - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From headius at headius.com Mon Apr 5 18:13:37 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 5 Apr 2010 20:13:37 -0500 Subject: Duby dynamic dispatch has landed! In-Reply-To: <82A7A393-56FB-4A1B-9460-CF48D27CA5FF@oracle.com> References: <82A7A393-56FB-4A1B-9460-CF48D27CA5FF@oracle.com> Message-ID: I will put together a duby-complete.jar that includes my bootstrap and requires you to provide Attila's dynalang stuff. I also posted a blog entry on how to build your own duby-complete; the missing piece is just additionally compiling and linking in src/org/jruby/duby/DynalangBootstrap.java: http://blog.headius.com/2010/04/getting-started-with-duby.html On Mon, Apr 5, 2010 at 6:16 PM, John Rose wrote: > The sources are changing rapidly at this point; I'm working on invokeGeneric. ?If you send me a JAR which which can run stand-alone, I can use it as a regression test. > > -- John > > On Apr 2, 2010, at 2:36 PM, Attila Szegedi wrote: > >> On 2010.03.25., at 3:17, Charles Oliver Nutter wrote: >> >>> For Attila: I had to remove a spreadArguments handle you used for >>> re-binding the method...not sure why. Here's the diff: >> >> Turns out, now the MethodHandle.invokeVarargs() actually does the whole convert-to-generic-and-invoke-as-vararg, so I committed the definitive solution for it now, which is simply: >> >> Index: DynamicLinkerImpl.java >> =================================================================== >> --- DynamicLinkerImpl.java ? ?(revision 233) >> +++ DynamicLinkerImpl.java ? ?(revision 228) >> @@ -111,6 +111,12 @@ >> ? ? ? ? // Invoke the method. Note we bypass the guard, as the assumption is >> ? ? ? ? // that the current arguments will pass the guard (and there actually >> ? ? ? ? // might be no guard at all). >> - ? ? ? ?return guardedInvocation.getInvocation().invokeVarargs(arguments); >> + ? ? ? ?final MethodHandle invocation = guardedInvocation.getInvocation(); >> + ? ? ? ?final MethodType genericType = invocation.type().generic(); >> + ? ? ? ?final MethodHandle genericizedInvocation = >> + ? ? ? ? ? ?MethodHandles.convertArguments(invocation, genericType); >> + ? ? ? ?final MethodHandle spreadInvocation = MethodHandles.spreadArguments( >> + ? ? ? ? ? ? ? ?genericizedInvocation, SPREAD_GENERIC_INVOCATION); >> + ? ? ? ?return MethodHandles.invoke(spreadInvocation, arguments); >> ? ? } >> } >> >> (Mind you, this is a reverse diff, but I'm too sleepy now to fix it; just swap + and -) >> >> I think the problem was in the fact that the (now deprecated) MethodHandles.invoke() used to behave as "invokeExact" in the last August's builds (so that's why I had to genericize + spread explicitly), while now it maps to MethodHandle.invokeVarargs(), so in addition to it being deprecated, its behaviour was also changed in the past half a year and that broke things, as you have yourself experienced :-). >> >> Should be good now. >> >> BTW, Stephen Bannasch's MLVM build works completely okay - I abandoned the attempt to now build my own as it didn't work out quickly and I didn't want to waste a lot of time; his version + Java sources from Mercurial seem sufficient for debugging. >> >> I'm still not back to the old 6 unit test errors, but this patch reduced them from 18 to 8; seems there are still two genuine new issues. >> >> Attila. >> >>> >>> Index: src/org/dynalang/dynalink/support/DynamicLinkerImpl.java >>> =================================================================== >>> --- src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (revision 232) >>> +++ src/org/dynalang/dynalink/support/DynamicLinkerImpl.java (working copy) >>> @@ -115,8 +115,6 @@ >>> ? ? ? ?final MethodType genericType = invocation.type().generic(); >>> ? ? ? ?final MethodHandle genericizedInvocation = >>> ? ? ? ? ? ?MethodHandles.convertArguments(invocation, genericType); >>> - ? ? ? ?final MethodHandle spreadInvocation = MethodHandles.spreadArguments( >>> - ? ? ? ? ? ? ? ?genericizedInvocation, SPREAD_GENERIC_INVOCATION); >>> - ? ? ? ?return MethodHandles.invoke(spreadInvocation, arguments); >>> + ? ? ? ?return MethodHandles.invoke(genericizedInvocation, arguments); >>> ? ?} >>> } >>> >>> I committed a built version with this hack...no tests, etc yet for >>> Duby's "dynamic" type, but that will come soon. >>> >>> BTW, what's the current state of the art for emitting .java with an >>> invokedynamic in it? Duby also has a .java backend, so I'll need to >>> add indy support there as well (somehow). >>> >>> - Charlie >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From john.r.rose at oracle.com Mon Apr 5 18:38:15 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 5 Apr 2010 18:38:15 -0700 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: <82A7A393-56FB-4A1B-9460-CF48D27CA5FF@oracle.com> Message-ID: <21041E9A-1E84-4889-8A00-42D8A329AAB4@oracle.com> Thanks; I appreciate the hand-holding. The more smoke tests the better. -- John On Apr 5, 2010, at 6:13 PM, Charles Oliver Nutter wrote: > I will put together a duby-complete.jar that includes my bootstrap and > requires you to provide Attila's dynalang stuff. I also posted a blog > entry on how to build your own duby-complete; the missing piece is > just additionally compiling and linking in > src/org/jruby/duby/DynalangBootstrap.java: > > http://blog.headius.com/2010/04/getting-started-with-duby.html From john.rose at sun.com Tue Apr 6 00:49:45 2010 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 06 Apr 2010 07:49:45 +0000 Subject: hg: mlvm/mlvm/jdk: meth: buglet with protected methods in 6939134 Message-ID: <20100406074947.1020F443BC@hg.openjdk.java.net> Changeset: b1506f926f77 Author: jrose Date: 2010-04-06 00:48 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b1506f926f77 meth: buglet with protected methods in 6939134 ! meth-ing-6939134.patch From lukas.stadler at jku.at Tue Apr 6 09:16:09 2010 From: lukas.stadler at jku.at (Lukas Stadler) Date: Tue, 06 Apr 2010 18:16:09 +0200 Subject: JRuby with coroutines Message-ID: <4BBB5E49.4050800@jku.at> Today I toyed around a little bit with JRuby and coroutines. I modified JRuby to use my coroutine implementation and ran some fiber-microbenchmarks. The results are pretty good: http://classparser.blogspot.com/2010/04/jruby-coroutines-really-fast.html I know that the gains won't be nearly as big in real-world applications, but it surely won't hurt... cheers, - Lukas From headius at headius.com Tue Apr 6 11:43:30 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Apr 2010 13:43:30 -0500 Subject: JRuby with coroutines In-Reply-To: <4BBB5E49.4050800@jku.at> References: <4BBB5E49.4050800@jku.at> Message-ID: Oh my god, this is awesome. I'll respond with more later. On Tue, Apr 6, 2010 at 11:16 AM, Lukas Stadler wrote: > Today I toyed around a little bit with JRuby and coroutines. > > I modified JRuby to use my coroutine implementation and ran some > fiber-microbenchmarks. The results are pretty good: > http://classparser.blogspot.com/2010/04/jruby-coroutines-really-fast.html > > I know that the gains won't be nearly as big in real-world applications, > but it surely won't hurt... > > cheers, > - Lukas > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From tom.enebo at gmail.com Tue Apr 6 11:47:05 2010 From: tom.enebo at gmail.com (Thomas E Enebo) Date: Tue, 6 Apr 2010 13:47:05 -0500 Subject: JRuby with coroutines In-Reply-To: <4BBB5E49.4050800@jku.at> References: <4BBB5E49.4050800@jku.at> Message-ID: Fabulous stuff. I should mention that our Ruby 1.9 mode still is in pure-interpreted mode so once we get our JIT hooked up these numbers should look even nicer! -Tom On Tue, Apr 6, 2010 at 11:16 AM, Lukas Stadler wrote: > Today I toyed around a little bit with JRuby and coroutines. > > I modified JRuby to use my coroutine implementation and ran some > fiber-microbenchmarks. The results are pretty good: > http://classparser.blogspot.com/2010/04/jruby-coroutines-really-fast.html > > I know that the gains won't be nearly as big in real-world applications, > but it surely won't hurt... > > cheers, > - Lukas > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.enebo at gmail.com From headius at headius.com Tue Apr 6 12:18:31 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Apr 2010 14:18:31 -0500 Subject: JRuby with coroutines In-Reply-To: <4BBB5E49.4050800@jku.at> References: <4BBB5E49.4050800@jku.at> Message-ID: Ok, I've had a chance to look your post over. Really awesome work! I've had it on my to-do list for weeks to get your stuff wired in, but never got around to it. So yeah, this is great and I'm ready to merge in changes *right now* :) Obviously you had to change things in JRuby, so we'd probably want to have a CoroutineFiberLibrary that we can reflectively load when coroutines are available, using the threaded version otherwise. There's also another form of fibers for Ruby 1.8 mode that's currently implemented mostly in Ruby called Generator, which works basically the same way (plus some creative finalization to allow generator threads to die when references to them die...it's not pretty). If we could get your FiberLibrary changes I can take it from there. It sounds like you also needed some changes in your stuff, like adding CoroutineLocals (which I totally punted on in the threaded Fiber), and maybe there's other bits and bobs. I'll look forward to seeing that merged into the patchset. In my opinion this proves that the coroutine work is worth trying to get into JDK7, even at this late stage. I'd even say it makes it worthwhile to run a hand-build JDK7 + coroutines if you have a use case that needs thousands of threadlets. Really awesome stuff. I'm standing by on IRC (freenode, "headius", #jruby) or IM ("headius" or "headiusmaximus" on the usual services) or email to work with you on this. I'm very excited! On Tue, Apr 6, 2010 at 11:16 AM, Lukas Stadler wrote: > Today I toyed around a little bit with JRuby and coroutines. > > I modified JRuby to use my coroutine implementation and ran some > fiber-microbenchmarks. The results are pretty good: > http://classparser.blogspot.com/2010/04/jruby-coroutines-really-fast.html > > I know that the gains won't be nearly as big in real-world applications, > but it surely won't hurt... > > cheers, > - Lukas > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From stephen.bannasch at deanbrook.org Tue Apr 6 16:31:51 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Tue, 6 Apr 2010 19:31:51 -0400 Subject: JRuby with coroutines In-Reply-To: <4BBB5E49.4050800@jku.at> References: <4BBB5E49.4050800@jku.at> Message-ID: At 6:16 PM +0200 4/6/10, Lukas Stadler wrote: >Today I toyed around a little bit with JRuby and coroutines. Kukas, that's exciting! Building today with guards="buildable testable" seems to include the coro.patch http://gist.github.com/358261 But I'm not able to successfully run CoroutineTest1.java referenced on this page: http://classparser.blogspot.com/2010/03/coroutines-for-java-status-update.html You can see the results here: http://gist.github.com/358264 I tried compiling w/o -Xbootclasspath/p:`pwd`/coroutine_classes.jar this worked: import java.dyn.Coroutine; but Java couldn't find the symbol: coYield(); This compiled w/o error: javac -Xbootclasspath/p:`pwd`/coroutine_classes.jar CoroutineTest1.java but running it generated this error: Exception in thread "main" java.lang.UnsatisfiedLinkError: java.dyn.CoroutineSupport.registerNatives()V From stephen.bannasch at deanbrook.org Tue Apr 6 20:07:44 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Tue, 6 Apr 2010 23:07:44 -0400 Subject: JRuby with coroutines In-Reply-To: References: <4BBB5E49.4050800@jku.at> Message-ID: If I set guards="buildable coro" I get patches that don't apply cleanly. When I run: hg qguard -l in sources/hotspot I see this for coro.patch: coro.patch: +coro -/coro +/meth +/indy +/callcc +/inti +/dynopt +1e976d3fd820 -testable I'm confused about how to interpret these two guards for coro.patch: '+coro' and '-/coro' What does the prefix '-/' signify? '-testable' is clear -- if I use the testable guard coro.patch won't be applied Setting testable prevents all of these patches from being applied in hotspot: $ hg qguard -l | grep testable indy-sparc-6829193.patch: -/indy +1e976d3fd820 -testable dynopt-6912064.patch: -/dynopt +1e976d3fd820 -testable meth-conv-6939861.patch: -/meth +1e976d3fd820 -testable annot.patch: +annot -/annot +d1605aabd0a1 +jdk7-b30 -testable callcc.patch: +callcc +/meth +/indy -/callcc +1e976d3fd820 -testable coro.patch: +coro -/coro +/meth +/indy +/callcc +/inti +/dynopt +1e976d3fd820 -testable From john.r.rose at oracle.com Tue Apr 6 20:27:52 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 6 Apr 2010 20:27:52 -0700 Subject: JRuby with coroutines In-Reply-To: References: <4BBB5E49.4050800@jku.at> Message-ID: On Apr 6, 2010, at 8:07 PM, Stephen Bannasch wrote: > I'm confused about how to interpret these two guards for coro.patch: '+coro' and '-/coro' > > What does the prefix '-/' signify? /foo by local convention means "not foo". Therefore, -/foo is a double negative. It may be needed (besides plain +foo) due to the rules hg uses to total up the effects of all the guards. -- John From headius at headius.com Tue Apr 6 20:29:57 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 6 Apr 2010 22:29:57 -0500 Subject: JSRs, JDKs, and coroutines Message-ID: Ok, I'll broach the question: What would it take to get coroutines into JDK7? Is it too late? Does it just need someone to lead a JSR? Of all the features in Ruby 1.8.7 and 1.9, the one that scares me the most is inbuilt coroutine support. We've so far managed to simulate them ok with threads, but as Lucas's post showed, we fall way behind on message-passing performance. And this says nothing about the cost of spinning up full native threads for short-lived coroutines while trying to guarantee their lifecycles don't root objects longer than they should. So, what's the situation? - Charlie From nicksieger at gmail.com Tue Apr 6 20:35:01 2010 From: nicksieger at gmail.com (Nick Sieger) Date: Tue, 6 Apr 2010 22:35:01 -0500 Subject: JRuby with coroutines In-Reply-To: <4BBB5E49.4050800@jku.at> References: <4BBB5E49.4050800@jku.at> Message-ID: On Tue, Apr 6, 2010 at 11:16 AM, Lukas Stadler wrote: > Today I toyed around a little bit with JRuby and coroutines. > > I modified JRuby to use my coroutine implementation and ran some > fiber-microbenchmarks. The results are pretty good: > http://classparser.blogspot.com/2010/04/jruby-coroutines-really-fast.html > > I know that the gains won't be nearly as big in real-world applications, > but it surely won't hurt... Looking forward to your openjdk and JRuby patches. In anticipation I tried to get openjdk w/ coro built on OS X. It seems there are a few missing pieces, which I blindly tried to fill in. I managed to get a build, but the VM dumps when trying to yield to a coroutine. All the gory details are here: http://gist.github.com/358484 Included above is a commit against the mlvm/hotspot repo, please review for correctness and feel free to commit if it looks good. The VM was crashing on an assert in unsafe.cpp: assert(target_coroutine == NULL, "expecting NULL"); What could be going wrong here? I haven't been able to untangle the coroutine magic quite yet... Cheers, /Nick From Christian.Thalinger at Sun.COM Wed Apr 7 05:07:37 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 07 Apr 2010 12:07:37 +0000 Subject: hg: mlvm/mlvm/hotspot: reset-thread-mh-flag-6941529: New patch. Message-ID: <20100407120739.4221344430@hg.openjdk.java.net> Changeset: 1d4a40eaec97 Author: twisti Date: 2010-04-07 14:06 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1d4a40eaec97 reset-thread-mh-flag-6941529: New patch. + reset-thread-mh-flag-6941529.patch ! series From Christian.Thalinger at Sun.COM Wed Apr 7 05:51:40 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Wed, 07 Apr 2010 12:51:40 +0000 Subject: hg: mlvm/mlvm/hotspot: indy-c1-sparc-6930772: New patch. Message-ID: <20100407125142.0A90C44431@hg.openjdk.java.net> Changeset: 31c0137dc777 Author: twisti Date: 2010-04-07 05:50 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/31c0137dc777 indy-c1-sparc-6930772: New patch. indy-c2-sparc-6934104: Likewise. + indy-c1-sparc-6930772.patch + indy-c2-sparc-6934104.patch ! series From forum at x9c.fr Wed Apr 7 09:52:34 2010 From: forum at x9c.fr (forum at x9c.fr) Date: Wed, 7 Apr 2010 18:52:34 +0200 Subject: Duby dynamic dispatch has landed! In-Reply-To: References: <2355438E-D61C-4D5B-9F30-E34F3869ADA1@gmail.com> <032AC890-C37A-487F-93AF-EFCB67CE2782@gmail.com> Message-ID: Le 5 avr. 2010 ? 04:56, Stephen Bannasch a ?crit : > At 10:41 PM +0200 4/2/10, Attila Szegedi wrote: >> So I decided to throw in the towel, and use Stephen Bannasch's excellent "update.sh" from >> >> It now bombs with: >> >> /Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/opto/runtime.cpp: In static member function 'static u_char* OptoRuntime::rethrow_C(oopDesc*, JavaThread*, u_char*)': >> /Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/opto/runtime.cpp:955: error: no matching function for call to 'SharedRuntime::raw_exception_handler_for_return_address(JavaThread*&, u_char*&)' >> /Users/aszegedi/Documents/projects/openjdk/bsd-port/hotspot/src/share/vm/runtime/sharedRuntime.hpp:101: note: candidates are: static u_char* SharedRuntime::raw_exception_handler_for_return_address(u_char*) >> make[6]: *** [runtime.o] Error 1 >> make[6]: *** Waiting for unfinished jobs.... >> make[5]: *** [the_vm] Error 2 >> make[4]: *** [product] Error 2 >> make[3]: *** [generic_build2] Error 2 >> make[2]: *** [product] Error 2 >> make[1]: *** [hotspot-build] Error 2 >> make: *** [build_product_image] Error 2 >> >> Digging backwards I can see this: >> >> + (cd sources/hotspot; hg qpush -a) >> abort: local changes found, refresh first >> *** Exit status 255. >> >> Does this mean that the current MLVM hotspot patches can't be applied to the tip of the bsd-port/hotspot? >> (Or am I doing something wrong?) > > Hi Attila, > > I've had that problem in the past. I think if I took the time to understand hg better the issue would be pretty clear. I solvedthe problem by recreating my local source repo (and added the instructions for doing this as comments in update.sh). Since then I have not had any errors where I couldn't update because of local changes. > > There have been times when the bsd-port code hasn't built properly for a while on 10.5 but that isn't the case now. > > I just built the latest bsd-port w/mlvm patches and it seems to work. > > I've uploaded a copy here: > http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_04_04.tar.gz Thanks for the build, it is saving me a great amount of time. I just stumbled upon a compiler exception, and do not know where it should be reported. I know that bugs against official releases should be reported to http://java.sun.com/webapps/bugreport but what about bugs against mlvm ? Just for the record, here is the program raising the compiler exception: public class C { public Object test(java.dyn.MethodHandle mh) throws Throwable { return mh.invokeExact(null); } } Thanks in advance for any insight, Xavier Clerc From lukas.stadler at jku.at Wed Apr 7 10:20:27 2010 From: lukas.stadler at jku.at (Lukas Stadler) Date: Wed, 07 Apr 2010 19:20:27 +0200 Subject: JRuby with coroutines In-Reply-To: <4BBB5E49.4050800@jku.at> References: <4BBB5E49.4050800@jku.at> Message-ID: <4BBCBEDB.5090309@jku.at> Wow, I didn't expect to instantly get that much feedback! I'm sorry, I should have updated the code examples to reflect the API changes I did last week. I'm currently writing a paper about the coroutine implementation for this year's PPPJ conference. That'll take up most of my time for the next two weeks. The line for coro.patch in the series file is really complicated, basically what I'd like to say is "if you want to apply coro.patch then you need to exclude all other patches". I suppose there's a simpler way to do that? Assertion on OS X: I really need to get myself an OS X machine. It currently runs fine on Ubuntu, I'll try to find out what's going wrong. And I have to give out a warning to all the brave ones trying this out: It's only a prototype, crashes from time to time and bites :-) - Lukas From headius at headius.com Wed Apr 7 10:55:50 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Wed, 7 Apr 2010 12:55:50 -0500 Subject: JRuby with coroutines In-Reply-To: <4BBCBEDB.5090309@jku.at> References: <4BBB5E49.4050800@jku.at> <4BBCBEDB.5090309@jku.at> Message-ID: On Wed, Apr 7, 2010 at 12:20 PM, Lukas Stadler wrote: > Wow, I didn't expect to instantly get that much feedback! > > I'm sorry, I should have updated the code examples to reflect the API > changes I did last week. > > I'm currently writing a paper about the coroutine implementation for > this year's PPPJ conference. That'll take up most of my time for the > next two weeks. > The line for coro.patch in the series file is really complicated, > basically what I'd like to say is "if you want to apply coro.patch then > you need to exclude all other patches". > I suppose there's a simpler way to do that? That's quite acceptable. I don't think most of the separate MLVM projects can be co-applied yet anyway. We just want your coroutine stuff so badly we're willing to have a build without indy (the horror!) to get it :) > Assertion on OS X: I really need to get myself an OS X machine. It > currently runs fine on Ubuntu, I'll try to find out what's going wrong. I'm sure someone on this list would be happy to give you access to such a machine, if you can't get access yourself. Seems like at least half of us here are running OS X machines. > And I have to give out a warning to all the brave ones trying this out: > It's only a prototype, crashes from time to time and bites :-) You have to walk before you can run! Seriously though, this is very exciting stuff, and I think we're all interested in helping if we can. - Charlie From john.r.rose at oracle.com Wed Apr 7 13:13:22 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 7 Apr 2010 13:13:22 -0700 Subject: JRuby with coroutines In-Reply-To: References: <4BBB5E49.4050800@jku.at> <4BBCBEDB.5090309@jku.at> Message-ID: <1070B16E-91F1-4A50-8E76-847362AE6CA0@oracle.com> On Apr 7, 2010, at 10:55 AM, Charles Oliver Nutter wrote: >> what I'd like to say is "if you want to apply coro.patch then >> you need to exclude all other patches". >> I suppose there's a simpler way to do that? If you use only the single guard +coro you should get that effect. Drop the other "standard" guards like "testable", the base revision hashcode, etc. Try "hg qguard --help" and "hg qselect --help" for info (very terse) about guards. > That's quite acceptable. I don't think most of the separate MLVM > projects can be co-applied yet anyway. We just want your coroutine > stuff so badly we're willing to have a build without indy (the > horror!) to get it :) Go for it! It is a patch garden, not a patch tower. -- John From Christian.Thalinger at Sun.COM Thu Apr 8 00:49:23 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Thu, 08 Apr 2010 09:49:23 +0200 Subject: JRuby with coroutines In-Reply-To: <4BBCBEDB.5090309@jku.at> References: <4BBB5E49.4050800@jku.at> <4BBCBEDB.5090309@jku.at> Message-ID: <1270712963.2639.238.camel@macbook> On Wed, 2010-04-07 at 19:20 +0200, Lukas Stadler wrote: > I'm currently writing a paper about the coroutine implementation for > this year's PPPJ conference. That'll take up most of my time for the > next two weeks. Hmpf. That reminds me that I promised to write one too about the JSR 292 implementation... -- Christian From Christian.Thalinger at Sun.COM Thu Apr 8 02:08:05 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Thu, 08 Apr 2010 09:08:05 +0000 Subject: hg: mlvm/mlvm/hotspot: reset-thread-mh-flag-6941529: Updated as commited. Message-ID: <20100408090806.A7B9A44458@hg.openjdk.java.net> Changeset: ebead183eeb7 Author: twisti Date: 2010-04-08 11:07 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ebead183eeb7 reset-thread-mh-flag-6941529: Updated as commited. ! reset-thread-mh-flag-6941529.patch From forax at univ-mlv.fr Thu Apr 8 05:07:42 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 08 Apr 2010 14:07:42 +0200 Subject: JRuby with coroutines In-Reply-To: <1270712963.2639.238.camel@macbook> References: <4BBB5E49.4050800@jku.at> <4BBCBEDB.5090309@jku.at> <1270712963.2639.238.camel@macbook> Message-ID: <4BBDC70E.9070904@univ-mlv.fr> Le 08/04/2010 09:49, Christian Thalinger a ?crit : > On Wed, 2010-04-07 at 19:20 +0200, Lukas Stadler wrote: > >> I'm currently writing a paper about the coroutine implementation for >> this year's PPPJ conference. That'll take up most of my time for the >> next two weeks. >> > Hmpf. That reminds me that I promised to write one too about the JSR > 292 implementation... > And I should do the same about the backport ... > -- Christian > R?mi From headius at headius.com Thu Apr 8 23:46:55 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 9 Apr 2010 01:46:55 -0500 Subject: Loop handle? Message-ID: It occurred to me today I may have never asked about this, but why is there no looping handle? (or have I missed something?) loopHandle(MethodHandle condition, MethodHandle body) In the current set of handles, I don't believe there's a way to construct a loop, since you can only link handles upwards from a target (i.e. there's no way to construct a handle to jump back to the condition again). Have I missed an obvious detail, or is this a gap in the set of handles? I ask because I still have a perverse desire to follow up on an idea John Rose gave me to implement JRuby's interpreter entirely with MethodHandles...with the obvious result being that by simply composing a set of handles they'll already be compiled to native code for me :) - Charlie From emmanuel.castro at laposte.net Fri Apr 9 00:20:08 2010 From: emmanuel.castro at laposte.net (Emmanuel Castro) Date: Fri, 9 Apr 2010 09:20:08 +0200 Subject: Loop handle? In-Reply-To: References: Message-ID: Maybe there is no need to have a special handle for loops if there is an (hidden?) support for tail call in method handles ;-) I remind me a blog page from John Rose: http://blogs.sun.com/jrose/entry/tailcalls_meet_invokedynamic There is questioning about putting coroutine in Java7. Will Java7 include the tail-call patch? I am not sure that it is compatible with the indy patch. Is there a plan to make it compatible? - Emmanuel 2010/4/9 Charles Oliver Nutter > > > It occurred to me today I may have never asked about this, but why is > there no looping handle? (or have I missed something?) > > loopHandle(MethodHandle condition, MethodHandle body) > > In the current set of handles, I don't believe there's a way to > construct a loop, since you can only link handles upwards from a > target (i.e. there's no way to construct a handle to jump back to the > condition again). > > Have I missed an obvious detail, or is this a gap in the set of handles? > > I ask because I still have a perverse desire to follow up on an idea > John Rose gave me to implement JRuby's interpreter entirely with > MethodHandles...with the obvious result being that by simply composing > a set of handles they'll already be compiled to native code for me :) > > - Charlie > _______________________________________________ > 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/20100409/3328cd54/attachment.html From headius at headius.com Fri Apr 9 00:58:48 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 9 Apr 2010 02:58:48 -0500 Subject: Loop handle? In-Reply-To: References: Message-ID: Yes, that thought crossed my mind. If tail calling were there, the only missing piece would be allowing a downstream handle (toward the target) to be able to be rebound to an upstream handle. Currently handles are a one-way street. On Fri, Apr 9, 2010 at 2:20 AM, Emmanuel Castro wrote: > Maybe there is no need to have a special handle for loops if there is an > (hidden?) support for tail call in method handles ;-) > I remind me a blog page from John Rose: > http://blogs.sun.com/jrose/entry/tailcalls_meet_invokedynamic > > There is questioning?about putting coroutine in Java7. Will Java7 include > the tail-call patch? I am not sure that it is compatible with the indy > patch. Is there a plan to make it compatible? > - Emmanuel > 2010/4/9 Charles Oliver Nutter >> >> >> It occurred to me today I may have never asked about this, but why is >> there no looping handle? (or have I missed something?) >> >> loopHandle(MethodHandle condition, MethodHandle body) >> >> In the current set of handles, I don't believe there's a way to >> construct a loop, since you can only link handles upwards from a >> target (i.e. there's no way to construct a handle to jump back to the >> condition again). >> >> Have I missed an obvious detail, or is this a gap in the set of handles? >> >> I ask because I still have a perverse desire to follow up on an idea >> John Rose gave me to implement JRuby's interpreter entirely with >> MethodHandles...with the obvious result being that by simply composing >> a set of handles they'll already be compiled to native code for me :) >> >> - Charlie >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > From fredrik.ohrstrom at oracle.com Fri Apr 9 02:53:07 2010 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 09 Apr 2010 11:53:07 +0200 Subject: Loop handle? In-Reply-To: References: Message-ID: <4BBEF903.6000407@oracle.com> Charles Oliver Nutter wrote: > I ask because I still have a perverse desire to follow up on an idea > John Rose gave me to implement JRuby's interpreter entirely with > MethodHandles...with the obvious result being that by simply composing > a set of handles they'll already be compiled to native code for me :) > It might be fun, but I do not think that it is a good idea to implement an interpreter in this way, or more precisely, to implement any interpreter of bytecodes, using Java. For languages like Ruby where the executable format is the source, I assume that your interpreter works on the source text by parsing/interpreting each source code line after each other. Since each interpreter step requires so much computation you will not gain any measurable performance by putting the interpreter loop inside the MethodHandle. On the other hand, if you interpret bytecodes, then each interpreter step is very small. At first it might look like a good idea to try to shave a few instructions from each interpreter step. But the whole point of achieving good performance on the JVM is that you translate the bytecodes of the other language into JVM bytecodes and then allow the JVM technology to do its magic. When you implement an interpreter with JVM bytecodes (or MethodHandles) then you immediately shut the door hard in the face of the JVM. It is simply impossible for the JVM to optimize >through< your interpreter loop into your application. The JVM will try to optimize your interpreter loop, but it is still only the interpreter loop. No variables will be optimized away from your code, no objects allocations will disappear, no inlining will happen! //Fredrik From headius at headius.com Fri Apr 9 11:23:03 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 9 Apr 2010 13:23:03 -0500 Subject: Loop handle? In-Reply-To: <4BBEF903.6000407@oracle.com> References: <4BBEF903.6000407@oracle.com> Message-ID: On Fri, Apr 9, 2010 at 4:53 AM, Fredrik ?hrstr?m wrote: > It might be fun, but I do not think that it is a good idea to implement > an interpreter in this way, > or more precisely, to implement any interpreter of bytecodes, using Java. I never said anything about a bytecode interpreter :) > For languages like Ruby where the executable format is the source, I > assume that your interpreter works on the source text by > parsing/interpreting each source code line after each other. Since each > interpreter step requires so much computation you will not gain any > measurable performance by putting the interpreter loop inside the > MethodHandle. In JRuby, we actually interpret Ruby code by walking the AST. It's a series of interpret calls chained form one to the next. So if we can represent Ruby code as a tree of executable objects of one kind... > On the other hand, if you interpret bytecodes, then each interpreter > step is very small. At first it might look like a good idea to try to > shave a few instructions from each interpreter step. > > But the whole point of achieving good performance on the JVM is that you > translate the bytecodes of the other language into JVM bytecodes and > then allow the JVM technology to do its magic. > > When you implement an interpreter with JVM bytecodes (or MethodHandles) > then you immediately shut the door hard in the face of the JVM. It is > simply impossible for the JVM to optimize >through< your interpreter > loop into your application. The JVM will try to optimize your > interpreter loop, but it is still only the interpreter loop. No > variables will be optimized away from your code, no objects allocations > will disappear, no inlining will happen! I think you misunderstand what I mean. I don't want to implement an interpreter using MethodHandles...I want to represent the actual Ruby code by recomposing the AST's structure in an identical structure of MethodHandles. In otherwords, a piece of code like this: if a.foo() # condition b + c # then else bar() # else end which would be an AST something like If ..Call "foo" # condition ....LocalVar "a" ..Call "+" # then ....LocalVar "b" ....LocalVar "c" ..Call "bar" # else would get recomposed into handles something like this: GuardWithTest ..InvokeDynamic "foo" # condition ....VariableLookup "a" ..InvokeDynamic "+" # then ....VariableLookup "b" ....VariableLookup "c" ..InvokeDynamic "bar # else And because direct method handles get composed together, it would essentially become the native code version of the Ruby AST, without any compile phase (or rather, the compile phase is the recomposition as DMHs). The reason a loop handle is needed is because there's "while" constructs in Ruby I need to represent somehow...*not* because I want to construct a bytecode loop: while a.foo # condition b.bar # body end needs to become Loop ..InvokeDynamic "foo" # condition ....VariableLookup "a" ..InvokeDynamic "bar" # body ....VariableLookup "b" There's no way to represent this using handles without a loop construct. Think about this more like if I were using LLVM and calling its various methods for representing variable/memory access, flow control, basic blocks, and so on. That's what I want: a toolkit for composing the spirit of my code in a recognizable form which then optimizes and assembles that spirit into native code (or bytecode). - Charlie From john.r.rose at oracle.com Fri Apr 9 16:24:28 2010 From: john.r.rose at oracle.com (John Rose) Date: Fri, 9 Apr 2010 16:24:28 -0700 Subject: Loop handle? In-Reply-To: References: Message-ID: On Apr 8, 2010, at 11:46 PM, Charles Oliver Nutter wrote: > In the current set of handles, I don't believe there's a way to > construct a loop, since you can only link handles upwards from a > target (i.e. there's no way to construct a handle to jump back to the > condition again). This is a good challenge for the MH API design! I've enclosed an example of how to write a couple such combinators in user code. I don't think they need to go into the standard, because (a) they are so easy to write and (b) they have too many degrees of design freedom. The really subtle thing would be a guarantee that certain MH combinators are properly tail recursive, so that you could write MH trees that embody open-ended threaded interpreters. I think all of the standard combinators should (at least as a matter of implementation quality) be properly tail-recursive in their last call when this is logically possible. If there is a conversion to be performed after the last call, this is difficult to do. I'm working right now on the JVM infrastructure for tail-recursive method handle adapters, and expect to make a number of built-in combinators properly tail-recursive in the RI. Guaranteeing such things in the spec. would require all JVMs to do the extra work. Is this worth it? I'm thinking it's not really worth while until the bytecodes themselves can also express proper tail calls. (I mean the "hard" version, that guarantee stack safety, not the "soft" kind that people expect from some optimizers; for the distinction, see the blog entry Emmanuel pointed out.) Given both combinators and regular methods that can perform tail calls, you could do the same kinds of chained control structures as Scheme and Haskell programmers enjoy. On Apr 9, 2010, at 12:58 AM, Charles Oliver Nutter wrote: > Yes, that thought crossed my mind. If tail calling were there, the > only missing piece would be allowing a downstream handle (toward the > target) to be able to be rebound to an upstream handle. Currently > handles are a one-way street. That's like what I've been (mysteriously) calling a "ricochet" adapter method handle. A ricochet calls two targets in succession; it feeds the result of the first target to the second, and (ideally) guarantees proper tail recursion on the second call. Would that be the sort of upstream rebounding you are thinking of? With an adapter like that, execution could ping-pong indefinitely through a series of first targets and ricochets; eventually a second target would return and the sequence would be over. Here's pseudocode for a single generic ricochet combinator: ricochet := lambda(first, second) { lambda(*args) { temp := first(*args) goto second(*args, temp) } } There are numerous variations on this, depending on how to share or split the argument list, and to merge in the temporary result value. The pattern itself is powerful and useful (at least, in the JVM implementation). With small variations, this is what several of the MethodHandles combinators do (notably filterArguments, but see how many others must include such logic!). The "flyby" adapter method handle (which I've also mentioned mysteriously at some points) would be a special kind of ricochet which reifies the argument list to the first target, and lets the target edit the arguments more or less "in place". I don't think we need this power, so I don't plan to fully design or implement it, unless the need turns up somewhere. At least, watch for ricochet stack frames, coming soon to a JVM near you. -- John P.S. There's some chance our mail server will drop the attached zip file. It's also posted here: http://blogs.sun.com/jrose/resource/jsr292/LoopHandle.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100409/aad82a2c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: LoopHandle.zip Type: application/zip Size: 3927 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100409/aad82a2c/attachment.zip -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100409/aad82a2c/attachment-0001.html From james at thorpeweb.com Sat Apr 10 03:45:08 2010 From: james at thorpeweb.com (James Thorpe) Date: Sat, 10 Apr 2010 20:45:08 +1000 Subject: Loop handle In-Reply-To: References: Message-ID: <813226BD-53CF-417A-B6DA-0971F49577E4@thorpeweb.com> This idea is a real gem! Would it not be possible to remove the need for a looping handle by a CPS conversion? James. On 10/04/2010, at 5:00 AM, mlvm-dev-request at openjdk.java.net wrote: > > I ask because I still have a perverse desire to follow up on an idea > John Rose gave me to implement JRuby's interpreter entirely with > MethodHandles...with the obvious result being that by simply composing > a set of handles they'll already be compiled to native code for me :) > > - Charlie From szegedia at gmail.com Sat Apr 10 08:20:00 2010 From: szegedia at gmail.com (Attila Szegedi) Date: Sat, 10 Apr 2010 17:20:00 +0200 Subject: JSR 292 RI status & javadoc checkpoint In-Reply-To: <4745D5A8-B7CC-407B-AD3C-29BDFD2765C5@sun.com> References: <4745D5A8-B7CC-407B-AD3C-29BDFD2765C5@sun.com> Message-ID: Hi, I'm updating my dyanalang-invoke module for the changes in the RI. Overall, all looks good. I noticed some things have been fixed, i.e. unreflect/findVirtual etc. now correctly create a MH with a MethodType that indicates the correct receiver type (and not generic java.lang.Object) even if it's not on the boot class path. There was also the bug of MethodHandles.catchException not working for exception types not on boot class path - I'll check that soon. However, collectArguments() still doesn't create the correct type of the array, but just a Object[]. I.e. this program: import java.dyn.MethodHandle; import java.dyn.MethodHandles; import java.dyn.MethodType; public class TestCollectArguments { public static void main(String[] args) throws Throwable { MethodHandle xs = MethodHandles.publicLookup().findVirtual( TestCollectArguments.class, "xs", MethodType.methodType( String.class, String.class, String[].class)); // This works System.out.println(xs.invokeVarargs(new TestCollectArguments(), "a", new String[] { "b", "c" })); MethodHandle collecting = MethodHandles.collectArguments(xs, MethodType.methodType(String.class, Object.class, String.class, String.class, String.class)); // This fails System.out.println(collecting.invokeVarargs(new TestCollectArguments(), "a", "b", "c")); } public String xs(String y, String... z) { for (String zz : z) { y += zz; } return y; } } will print: abc Exception in thread "main" java.lang.ClassCastException: required class [Ljava.lang.String; but encountered class [Ljava.lang.Object; at sun.dyn.MethodHandleImpl.raiseException(MethodHandleImpl.java:1246) at sun.dyn.FilterGeneric$F4.invoke_C2(FilterGeneric.java:629) at sun.dyn.ToGeneric$A4.target(ToGeneric.java:746) at sun.dyn.ToGeneric$A4.targetA4(ToGeneric.java:747) at sun.dyn.ToGeneric$A4.invoke_L(ToGeneric.java:756) at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:334) at TestCollectArguments.main(TestCollectArguments.java:21) Any plans to have this fixed soon? I can alternatively code a workaround using filterArguments... Attila. On 2010.03.25., at 11:29, John Rose wrote: > The JSR 292 EG has been working with me to refine and clarify the spec for invokedynamic. I have pushed updates to the RI to reflect this ongoing work. For the record, here is javadoc for the current state of the RI: > > http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/ > > The presentation and logic of the javadoc is not perfect. Please do send me your suggestions for improvement! > > Here are some holes in the implementation that I know about and will fix soon: > > - translation from signatures to method types sometimes fails on classes not on the boot class path > > - java.dyn.MethodHandle inherits from a type MethodHandleImpl that needs to go away > > - adapter method handles cannot be built for some signatures, including those for which primitives precede references > > - MH.invokeGeneric behaves the same as MH.invokeExact (oops: it is supposed to be more permissive) > > Best wishes, > -- John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From szegedia at gmail.com Sat Apr 10 08:51:21 2010 From: szegedia at gmail.com (Attila Szegedi) Date: Sat, 10 Apr 2010 17:51:21 +0200 Subject: dynalang-invoke updated for latest JSR-292 API Message-ID: <4A4B4F9B-62BA-4DA0-AD5D-BD35AE976927@gmail.com> Folks, I just updated the dynalang-invoke SVN trunk tip to use the latest JSR-292 API (as documented on ). It works with latest prebuilt Mac OS X MLVM that Stephen Bannasch put up at . Older dynalang-invoke would probably also work, but I have now also eliminated use of all previously used, but now deprecated APIs. Attila. From headius at headius.com Sat Apr 10 11:28:00 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Sat, 10 Apr 2010 13:28:00 -0500 Subject: Loop handle In-Reply-To: <813226BD-53CF-417A-B6DA-0971F49577E4@thorpeweb.com> References: <813226BD-53CF-417A-B6DA-0971F49577E4@thorpeweb.com> Message-ID: With tail calling, it would certainly be possible. I think the tradeoff would be accepting that you wouldn't be able to completely compose a body of code in one shot; somewhere downstream you'd have to defer a decision like whether to exit the loop or not. That would probably mean slicing the native side into pieces, at least until profiled inlining could happen. It's worth pointing out that JRuby's current interpreter does actually inline in places, wherever the AST structure is invariant. We actually reified several variants of calls by arity and block-passing to both simplify logic and to expand the number of unique Node subtypes for Hotspot to key off. The move to composed handles would be like generating unique classes for every node instance in the system, effectively making all node to node calls monomorphic and trivially inlinable. Maybe I'll try to mock up an AST to MH translator for the pieces we can currently represent. Another important detail comes to mind now as well: when a graph of handles becomes large enough that it's no longer a good idea to compile the whole thing, it should gracefully degrade into multiple compiled pieces, rather than bailing out completely to full interpretation. That bites us surprisingly often with Ruby's very dense code...we frequently end up generating methods that are too "fat" for Hotspot's default thresholds. - Charlie On Saturday, April 10, 2010, James Thorpe wrote: > This idea is a real gem! > > Would it not be possible to remove the need for a looping handle by a > CPS conversion? > > James. > > > On 10/04/2010, at 5:00 AM, mlvm-dev-request at openjdk.java.net wrote: > >> >> I ask because I still have a perverse desire to follow up on an idea >> John Rose gave me to implement JRuby's interpreter entirely with >> MethodHandles...with the obvious result being that by simply composing >> a set of handles they'll already be compiled to native code for me :) >> >> - Charlie > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From james at thorpeweb.com Sat Apr 10 15:01:02 2010 From: james at thorpeweb.com (James Thorpe) Date: Sun, 11 Apr 2010 08:01:02 +1000 Subject: Loop handle In-Reply-To: References: <813226BD-53CF-417A-B6DA-0971F49577E4@thorpeweb.com> Message-ID: <422F6F17-C2CA-4315-B8F5-EE778979C6DA@thorpeweb.com> If CPS is out - what about passing the loop condition and body into a function that does the looping for you. in pseudo code defn loop_fn(cond, body) while (cond()) do body() end end this avoids the need for tail calls entirely - and I presume the whole lot could be inlined. James. From john.r.rose at oracle.com Sat Apr 10 16:27:43 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 10 Apr 2010 16:27:43 -0700 Subject: Loop handle In-Reply-To: <422F6F17-C2CA-4315-B8F5-EE778979C6DA@thorpeweb.com> References: <813226BD-53CF-417A-B6DA-0971F49577E4@thorpeweb.com> <422F6F17-C2CA-4315-B8F5-EE778979C6DA@thorpeweb.com> Message-ID: <9108B6E0-1BA5-4311-AEAA-19C4C624FBDB@oracle.com> On Apr 10, 2010, at 3:01 PM, James Thorpe wrote: > If CPS is out - what about passing the loop condition and body into a > function that does the looping for you. http://blogs.sun.com/jrose/resource/jsr292/LoopHandle.zip -- John From fcassia at gmail.com Sat Apr 10 23:46:28 2010 From: fcassia at gmail.com (Fernando Cassia) Date: Sun, 11 Apr 2010 03:46:28 -0300 Subject: Oracle Basic (Powerobjects), Basic-like language running on the JVM, ever ? Message-ID: Hi there, 1) I?ve read that the goal of this JSR and project is to bring other languages to the JVM with the same performance as java bytecode. Would this be like what Mono currently has?, I mean, the ability to develop third party add-ons that interface with the JVM engine, thus allowing for plenty of languages to run in the JVM?. (Sorry, I?m asking as an end user, not a developer). 2) Now that Oracle owns Sun, perhpas it?d be a good idea to bring a Basic-like language to the JVM too. I remember Oracle had its OracleBasic as part of its PowerObjects package... or to revive the defunct Project Semplice that aimed to run Visual Basic syntax programs and compile those as Java bytecode. Three years ago, Sun Microsystems had a project to bring Visual Basic (VB) programmers to the Java platform, with an IDE that would just compile VB source code directly as Java bytecode, letting VB programmers create 100% Pure Java applications More info: http://blogs.sun.com/herbertc/entry/project_semplice_visual_basic_for With no Java learning curve, this would have brought millions of hobbyist programmers to the cross-platform, Java bytecode platform. Unfortunately, the programmers in charge of Project Semplice left Sun. With the current push for JavaFX, I think this is an excellent chance for Sun to bring Project Semplice back to life as a Visual Basic to Java (or JavaFX) translator. I?ve created a Facebook Group to ask Sun about this. Those interested, feel free to join http://www.facebook.com/group.php?gid=56023420682&ref=ts 3) For the record, here?s what Oracle Basic was (is?) ------ "Oracle kept the developer in mind when choosing the programming language for Power Objects?Oracle Basic. Oracle Basic is extremely similar to Visual Basic, with the additions of object extensions and Structured Query Language (SQL) extensions. BASIC is the most commonly-used programming language. Any developer familiar with any version of BASIC will be able to quickly and easily transition to writing Oracle Basic code in Power Objects. " http://docs.rinet.ru/Krikun/oun36fi.htm ------ 4) Why Visual Basic (or Oracle Basic, or OpenOffice Basic): because there?s still hundreds of thousands of hobby programmers out there with Visual Basic or Basic-language skills. See what Sun is missing by not releasing Project Semplice February 2009 survey shows VB6 still alive and kicking http://www.itjoblog.co.uk/2009/02/visual-basic-6-the-runtime-tha.html 5) In all these years for which I?ve been a Java VM user and advocate, I always thought it was a shame that plenty of people in the java camp became "Java language zealots" overlooking the possibilities of the Java VM as a runtime for OTHER languages. At least IBM?s Mike Cowlishaw realized this and created NetRexx, giving Rexx language programmers the ability to write code in the language they already knew, and create java bytecode from it. In short: People should be able to just fire an IDE, start typing in whatever language they know (VISUAL BASIC, PASCAL, PYTHON, etc) and then "compile as java bytecode", ending in a .jar file. Bringing Sun?s "Project Semplice" back to life would be a good start. Would MLVM make this easier to accomplish?. So... to make this long tirade short.... ?Does what I say make any sense? Is there a chance of getting an "Oracle Basic" like language supported by the Java VM thanks to mlvm ?? Any contacts at Sun / Oracle to pursue this? Best, FC -- "Me gustar?a vivir un tiempo razonable. Qu? se yo, mil, dos mil a?os". -Ernesto S?bato From john.r.rose at oracle.com Tue Apr 13 22:55:23 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 14 Apr 2010 05:55:23 +0000 Subject: hg: mlvm/mlvm/jdk: meth: first working ricochet, used for boxing conversions Message-ID: <20100414055524.D0B3D44546@hg.openjdk.java.net> Changeset: cf851e2e74bf Author: jrose Date: 2010-04-13 22:55 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/cf851e2e74bf meth: first working ricochet, used for boxing conversions ! meth-conv-6939861.patch ! series From john.r.rose at oracle.com Tue Apr 13 23:11:40 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 14 Apr 2010 06:11:40 +0000 Subject: hg: mlvm/mlvm/hotspot: 5 new changesets Message-ID: <20100414061142.41FB844547@hg.openjdk.java.net> Changeset: 0b907e1e6b89 Author: jrose Date: 2010-04-06 00:55 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0b907e1e6b89 clean up a stray trailing space ! indy-c1-x86-6919934.patch ! meth-ing-6939134.patch Changeset: f2962d341152 Author: jrose Date: 2010-04-06 00:56 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f2962d341152 cpindex-6939207: finish cleanup of byte-order hacks ! cpindex-6939207.patch ! meth-ldc-6939203.patch Changeset: 35cd12ca5311 Author: jrose Date: 2010-04-13 22:53 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/35cd12ca5311 Merge Changeset: 9f2f7630ec2f Author: jrose Date: 2010-04-13 22:54 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9f2f7630ec2f meth: first working ricochet, used for boxing conversions ! meth-conv-6939861.patch ! series Changeset: 29f5346e477b Author: jrose Date: 2010-04-13 23:11 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/29f5346e477b meth: move assembly helper declarations into PD header file for sparc ! meth-conv-6939861.patch From Christian.Thalinger at Sun.COM Wed Apr 14 01:40:59 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 14 Apr 2010 10:40:59 +0200 Subject: hg: mlvm/mlvm/hotspot: 5 new changesets In-Reply-To: <20100414061142.41FB844547@hg.openjdk.java.net> References: <20100414061142.41FB844547@hg.openjdk.java.net> Message-ID: <1271234459.2134.169.camel@macbook> On Wed, 2010-04-14 at 06:11 +0000, john.r.rose at oracle.com wrote: > Changeset: 29f5346e477b > Author: jrose > Date: 2010-04-13 23:11 -0700 > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/29f5346e477b > > meth: move assembly helper declarations into PD header file for sparc > > ! meth-conv-6939861.patch Maybe we can add now a methodHandles_.hpp for all architectures and move the enum method_handles_platform_dependent_constants from stubRoutines_.hpp there? -- Christian From john.r.rose at oracle.com Wed Apr 14 20:46:56 2010 From: john.r.rose at oracle.com (John Rose) Date: Wed, 14 Apr 2010 20:46:56 -0700 Subject: hg: mlvm/mlvm/hotspot: 5 new changesets In-Reply-To: <1271234459.2134.169.camel@macbook> References: <20100414061142.41FB844547@hg.openjdk.java.net> <1271234459.2134.169.camel@macbook> Message-ID: <73976F8B-2991-4F43-8A90-8CC84DBE7BC8@oracle.com> Yes, meth-conv has the header split like that. Apologies in advance: I have not built meth-conv on sparc yet. If you want to move the header file split from meth-conv into an earlier patch, and have the cycles to do so, feel free. -- John On Apr 14, 2010, at 1:40 AM, Christian Thalinger wrote: > Maybe we can add now a methodHandles_.hpp for all architectures > and move the enum method_handles_platform_dependent_constants from > stubRoutines_.hpp there? From headius at headius.com Mon Apr 19 15:22:31 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 19 Apr 2010 17:22:31 -0500 Subject: Student proposals needed for Ruby Summer of Code 2010 Message-ID: The Ruby Summer of Code call for student proposals closes THIS FRIDAY, and there's still room for more students to jump in. I'd love to see some folks get paid to work on JRuby projects over the summer, and we've put up a list of ideas here: http://kenai.com/projects/jruby/pages/RubySummerOfCode2010 There's also Ruby and Rails ideas on the RubySOC page at http://rubysoc.org/students, where you can also find the proposal form. What could be better than getting paid to work on OSS over the summer while familiarizing yourself with a strong JVM language implementation (i.e. JRuby)! And also, if you know any students that might be interested in RubySOC or professors/colleges/universities that might have such students, please pass this along to them. Thanks :) - Charlie From john.r.rose at oracle.com Wed Apr 21 23:38:22 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 22 Apr 2010 06:38:22 +0000 Subject: hg: mlvm/mlvm/langtools: meth: tweak error checks regarding PolymorphicSignatures attributes Message-ID: <20100422063822.D1BC744658@hg.openjdk.java.net> Changeset: d135a49a1ff7 Author: jrose Date: 2010-04-21 23:38 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/d135a49a1ff7 meth: tweak error checks regarding PolymorphicSignatures attributes ! meth-ing-6939134.patch From john.r.rose at oracle.com Thu Apr 22 00:19:17 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 22 Apr 2010 07:19:17 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-ldc: incorporate reviewer comments Message-ID: <20100422071918.355D844659@hg.openjdk.java.net> Changeset: 79b01fac0f61 Author: jrose Date: 2010-04-22 00:19 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/79b01fac0f61 meth-ldc: incorporate reviewer comments ! meth-ldc-6939203.patch From john.r.rose at oracle.com Thu Apr 22 00:19:47 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 22 Apr 2010 07:19:47 +0000 Subject: hg: mlvm/mlvm/jdk: meth-ldc: incorporate reviewer comments Message-ID: <20100422071948.02FA04465A@hg.openjdk.java.net> Changeset: 5deb3e03e277 Author: jrose Date: 2010-04-22 00:19 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/5deb3e03e277 meth-ldc: incorporate reviewer comments ! meth-conv-6939861.patch ! meth-ldc-6939203.patch From john.r.rose at oracle.com Thu Apr 22 00:24:27 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 22 Apr 2010 07:24:27 +0000 Subject: hg: mlvm/mlvm/jdk: meth-conv: disable unfinished code (oops) Message-ID: <20100422072427.E63FB4465B@hg.openjdk.java.net> Changeset: 4a3f69ef4189 Author: jrose Date: 2010-04-22 00:24 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4a3f69ef4189 meth-conv: disable unfinished code (oops) ! meth-conv-6939861.patch From john.r.rose at oracle.com Thu Apr 22 00:48:40 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 22 Apr 2010 07:48:40 +0000 Subject: hg: mlvm/mlvm/hotspot: cpindex: incorporate reviewer comments Message-ID: <20100422074840.F12734465F@hg.openjdk.java.net> Changeset: 97b183943d84 Author: jrose Date: 2010-04-22 00:47 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/97b183943d84 cpindex: incorporate reviewer comments ! cpindex-6939207.patch From John.Rose at Sun.COM Thu Apr 22 12:39:23 2010 From: John.Rose at Sun.COM (John Rose) Date: Thu, 22 Apr 2010 12:39:23 -0700 Subject: Replacing # with backticks for exotic identifiers In-Reply-To: References: Message-ID: <49ABAA8F-1E23-4A54-BCD7-65734AD0382E@sun.com> I was updating the Project Coin proposal to take invokeGeneric into account, and added some paragraphs of rationale about the ugly #"exotic identifier" syntax, since that decision sometimes gets comments. http://wikis.sun.com/display/mlvm/InterfaceDynamic In this case, ugly is better than pretty because anything pretty is going to pre-empt a more worthy use of the pretty syntax. BTW, there is now a patch in the mlvm repository which implements a prototype for method handle literals in the FCM style. This demonstrates (though there was no credible doubt before) that there is no ambiguity among the various proposed lexical uses of '#'. Using '#' in two different tokens is just as safe and clear as using the characters '/' '*' 'x' 'e' for various tokens. Best wishes, -- John On Nov 27, 2009, at 3:20 PM, Paul Benedict wrote: > Hello, > > I didn't initiate this suggestion, but I am passing it along because > it is really good, imo. Furthermore, I've complained about the #"" > syntax and, well, I still complain about it :-) > > Artur Biesiadowski, in the Coin Dev mailing list, made the suggestion > to replace the #"" notation with backticks [1]. I think his suggestion > was great for at least four reasons: > > 1) Closures might use pound symbol > 2) Method literals might use pound symbol > 3) JavaDoc already uses pound symbol > 4) Backticks are commonly supported by several RDMS to represent > exotic identifiers (like table names with spaces). > > Is the pound symbol really the choice favorite by the participants in > this list? John and Remi, unless your heart is set on it, can you > consider a change with regards to all the other language changes now > going to happen? > > Paul > > [1] http://mail.openjdk.java.net/pipermail/coin-dev/2009-November/002556.html > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From Christian.Thalinger at Sun.COM Mon Apr 26 02:52:58 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 26 Apr 2010 09:52:58 +0000 Subject: hg: mlvm/mlvm/hotspot: Rebased to jdk7-b89. Message-ID: <20100426095258.A6A794416D@hg.openjdk.java.net> Changeset: b55ebb49337b Author: twisti Date: 2010-04-26 11:50 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b55ebb49337b Rebased to jdk7-b89. ! cpindex-6939207.patch ! indy-c1-sparc-6930772.patch ! indy-sparc-6829193.patch ! meth-conv-6939861.patch ! series From Christian.Thalinger at Sun.COM Mon Apr 26 02:53:10 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 26 Apr 2010 09:53:10 +0000 Subject: hg: mlvm/mlvm/jdk: Rebased to jdk7-b89. Message-ID: <20100426095310.F0E214416E@hg.openjdk.java.net> Changeset: ee00dc245baf Author: twisti Date: 2010-04-26 11:50 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ee00dc245baf Rebased to jdk7-b89. ! series From Christian.Thalinger at Sun.COM Mon Apr 26 02:53:18 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 26 Apr 2010 09:53:18 +0000 Subject: hg: mlvm/mlvm/langtools: Rebased to jdk7-b89. Message-ID: <20100426095318.7FD754416F@hg.openjdk.java.net> Changeset: 30b47eb3dafb Author: twisti Date: 2010-04-26 11:50 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/30b47eb3dafb Rebased to jdk7-b89. ! series