From raffaello.giulietti at gmail.com Mon Nov 2 00:36:28 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 02 Nov 2009 09:36:28 +0100 Subject: mlvm don't build In-Reply-To: <4AEC59CC.9010605@univ-mlv.fr> References: <4AEC59CC.9010605@univ-mlv.fr> Message-ID: <4AEE9A0C.5090101@gmail.com> R?mi Forax wrote: > No way to apply the patch series as is. > > + (cd sources/hotspot; hg qpush -a) > applying snowleopard.patch > applying meth-6815692.patch > applying indy-6858164.patch > applying indy-amd64.patch > applying meth.walker.patch > applying indy-cleanup-6893081.patch > applying indy.compiler.patch > skipping indy.compiler.inline.patch - guarded by '-testable' > skipping dynopt.patch - guarded by '-buildable' > skipping indy-sparc.patch - guarded by '-buildable' > skipping meth.proj.patch - guarded by ['+projects'] > skipping anonk.proj.patch - guarded by ['+projects'] > skipping annot.patch - guarded by '-testable' > skipping inti.patch - guarded by '-buildable' > skipping callcc.patch - guarded by '-testable' > skipping tailc.patch - guarded by ['+tailc-lazy'] > skipping tailc-eager.patch - guarded by ['+tailc-lazy'] > skipping hotswap.patch - guarded by ['+hotswap'] > now at: indy.compiler.patch > + (cd sources/jdk; hg qpush -a) > applying regtest-6891770.patch > applying indy.tests.patch > patching file test/java/dyn/MethodHandlesTest.java > Hunk #2 FAILED at 110 > 1 out of 16 hunks FAILED -- saving rejects to file > test/java/dyn/MethodHandlesTest.java.rej > patch failed, unable to continue (try -v) > patch failed, rejects left in working dir > errors during apply, please fix and refresh indy.tests.patch > *** Exit status 2. > + (cd sources/langtools; hg qpush -a) > applying meth.patch > skipping dyncast.patch - guarded by ['+dyncast'] > skipping tailc.patch - guarded by ['+tailc'] > now at: meth.patch > > indy.tests.patch seems to be the offending patch. > > R?mi > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev R?mi, you're not alone! Same issue for me on OpenSolaris 32 bits. Raffaello From yung2.alan at gmail.com Wed Nov 4 02:14:25 2009 From: yung2.alan at gmail.com (alan yung) Date: Wed, 4 Nov 2009 02:14:25 -0800 Subject: Rebuilding rt.jar Message-ID: <6b6a329a0911040214t5fdf589cp6a82bf947367e778@mail.gmail.com> If I want to re-generate rt.jar file in j2sdk image, where should i build? For instance, if I change something in java/dyn/, building in jdk/make/java/dyn doesn't seem to regenerate rt.jar file, thus the change doesn't take effect. What do I do to regenerate rt.jar? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091104/ec15399c/attachment.html From Christian.Thalinger at Sun.COM Wed Nov 4 03:39:46 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 04 Nov 2009 12:39:46 +0100 Subject: Rebuilding rt.jar In-Reply-To: <6b6a329a0911040214t5fdf589cp6a82bf947367e778@mail.gmail.com> References: <6b6a329a0911040214t5fdf589cp6a82bf947367e778@mail.gmail.com> Message-ID: <1257334786.15728.38.camel@macbook> On Wed, 2009-11-04 at 02:14 -0800, alan yung wrote: > If I want to re-generate rt.jar file in j2sdk image, where should i > build? > For instance, if I change something in java/dyn/, building in > jdk/make/java/dyn doesn't seem to regenerate rt.jar file, thus the > change doesn't take effect. > What do I do to regenerate rt.jar? Hmm, I don't know if there is a target for it (I guess not a trivial one, you could ask on core-libs-dev or build-dev) but simply removing rt-orig.jar from tmp/ in the build directory should do the job. -- Christian From james_ladd at hotmail.com Wed Nov 4 12:49:28 2009 From: james_ladd at hotmail.com (James Ladd) Date: Thu, 5 Nov 2009 07:49:28 +1100 Subject: Which bytecode generator ? In-Reply-To: References: Message-ID: Hi All, I'm wondering which bytecode generation library I should use for my SmalltalkJVM project? What do you recommend? Rgs, James. _________________________________________________________________ For more of what happens online Head to the Daily Blob on Windows Live http://windowslive.ninemsn.com.au/blog.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091105/8bd5b1ab/attachment.html From forax at univ-mlv.fr Wed Nov 4 13:14:10 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 04 Nov 2009 22:14:10 +0100 Subject: Which bytecode generator ? In-Reply-To: References: Message-ID: <4AF1EEA2.5030908@univ-mlv.fr> Le 04/11/2009 21:49, James Ladd a ?crit : > Hi All, > > I'm wondering which bytecode generation library I should use for my > SmalltalkJVM > project? What do you recommend? ASM: http://asm.ow2.org/ version 3.2 has support for invokedynamic. > > Rgs, James. cheers, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091104/64cff669/attachment.html From yung2.alan at gmail.com Thu Nov 5 03:41:18 2009 From: yung2.alan at gmail.com (alan yung) Date: Thu, 5 Nov 2009 03:41:18 -0800 Subject: Rebuilding rt.jar In-Reply-To: <1257334786.15728.38.camel@macbook> References: <6b6a329a0911040214t5fdf589cp6a82bf947367e778@mail.gmail.com> <1257334786.15728.38.camel@macbook> Message-ID: <6b6a329a0911050341l21d4f213wbb869966f35cc5d0@mail.gmail.com> But where should I do the build? (I don't want to build in jdk/make since it takes some time) On Wed, Nov 4, 2009 at 3:39 AM, Christian Thalinger < Christian.Thalinger at sun.com> wrote: > On Wed, 2009-11-04 at 02:14 -0800, alan yung wrote: > > If I want to re-generate rt.jar file in j2sdk image, where should i > > build? > > For instance, if I change something in java/dyn/, building in > > jdk/make/java/dyn doesn't seem to regenerate rt.jar file, thus the > > change doesn't take effect. > > What do I do to regenerate rt.jar? > > Hmm, I don't know if there is a target for it (I guess not a trivial > one, you could ask on core-libs-dev or build-dev) but simply removing > rt-orig.jar from tmp/ in the build directory should do the job. > > -- Christian > > _______________________________________________ > 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/20091105/b8d678e8/attachment.html From james_ladd at hotmail.com Fri Nov 6 00:24:50 2009 From: james_ladd at hotmail.com (James Ladd) Date: Fri, 6 Nov 2009 19:24:50 +1100 Subject: Which bytecode generator ? In-Reply-To: References: Message-ID: Is there a lite / simpler bytecode generation library than ASM ? _________________________________________________________________ Download new and classic emoticon packs at Emoticon World Brought to you exclusively by Windows Live http://windowslive.ninemsn.com.au/emoticon.aspx? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091106/2bf2de20/attachment.html From pdoubleya at gmail.com Fri Nov 6 00:35:53 2009 From: pdoubleya at gmail.com (Patrick Wright) Date: Fri, 6 Nov 2009 09:35:53 +0100 Subject: Which bytecode generator ? In-Reply-To: References: Message-ID: <64efa1ba0911060035k75e695f0n7eff49fa2e914b08@mail.gmail.com> Here's a collection of links, there are a number of libraries for this--ASM has become the most popular over the last few years, but there are alternatives http://groups.google.com/group/jvm-languages/web/jvm-bytecode-libraries On Fri, Nov 6, 2009 at 9:24 AM, James Ladd wrote: > Is there a lite / simpler? bytecode generation library than ASM ? From John.Rose at Sun.COM Tue Nov 10 11:09:32 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 10 Nov 2009 11:09:32 -0800 Subject: a paper on invokedynamic Message-ID: <636798D9-0DAF-4FD6-AEB2-377271E82C9A@sun.com> Dear colleagues, I have written a paper for VMIL '09 on invokedynamic, which you may find interesting: Bytecodes meet Combinators: invokedynamic on the JVM John Rose, VMIL '09 Workshop at OOPSLA, Orlando, October 2009 http://cr.openjdk.java.net/~jrose/pres/200910-VMIL.pdf The focus of the paper is on evaluating the architectural effect of adding invokedynamic to JVM bytecodes. The description of JSR 292 is partial and provisional but I expect the part I have described is mostly stable. There is a lot of overview of (a) current implementation techniques for JVM languages, (b) how these techniques adapt to invokedynamic, and (c) how a JVM might optimize invokedynamic. The treatment mentions HotSpot in a few places, but is not specific (not intentionally so, at least) to HotSpot. I hope it is useful to other JVM teams and to dynamic language implementors. Best wishes, -- John From musachy at gmail.com Tue Nov 10 12:02:49 2009 From: musachy at gmail.com (Musachy Barroso) Date: Tue, 10 Nov 2009 12:02:49 -0800 Subject: a paper on invokedynamic In-Reply-To: <636798D9-0DAF-4FD6-AEB2-377271E82C9A@sun.com> References: <636798D9-0DAF-4FD6-AEB2-377271E82C9A@sun.com> Message-ID: small typo in the first page "There is no multiple dispatch [Musch08] ni the JVM" (unless you are one of "the knights who say ni" :) ) musachy On Tue, Nov 10, 2009 at 11:09 AM, John Rose wrote: > Dear colleagues, > > I have written a paper for VMIL '09 on invokedynamic, which you may > find interesting: > ? Bytecodes meet Combinators: invokedynamic on the JVM > ? John Rose, VMIL '09 Workshop at OOPSLA, Orlando, October 2009 > ? http://cr.openjdk.java.net/~jrose/pres/200910-VMIL.pdf > > The focus of the paper is on evaluating the architectural effect of > adding invokedynamic to JVM bytecodes. ?The description of JSR 292 is > partial and provisional but I expect the part I have described is > mostly stable. ?There is a lot of overview of (a) current > implementation techniques for JVM languages, (b) how these techniques > adapt to invokedynamic, and (c) how a JVM might optimize > invokedynamic. ?The treatment mentions HotSpot in a few places, but is > not specific (not intentionally so, at least) to HotSpot. ?I hope it > is useful to other JVM teams and to dynamic language implementors. > > Best wishes, > -- John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From John.Rose at Sun.COM Tue Nov 10 12:19:25 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 10 Nov 2009 12:19:25 -0800 Subject: a paper on invokedynamic In-Reply-To: References: <636798D9-0DAF-4FD6-AEB2-377271E82C9A@sun.com> Message-ID: <1607759A-32C5-4AE7-903D-BFA3E50DDE61@sun.com> Thanks! I owe you a shrubbery. :-) Fixed. -- John On Nov 10, 2009, at 12:02 PM, Musachy Barroso wrote: > small typo in the first page "There is no multiple dispatch [Musch08] > ni the JVM" (unless you are one of "the knights who say ni" :) ) From lukas.stadler at jku.at Thu Nov 12 09:03:58 2009 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Thu, 12 Nov 2009 17:03:58 +0000 Subject: hg: mlvm/mlvm/hotspot: callcc bugfixes Message-ID: <20091112170359.38BC4414C7@hg.openjdk.java.net> Changeset: bf5b4b1bca33 Author: lstadler Date: 2009-11-12 17:11 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/bf5b4b1bca33 callcc bugfixes ! callcc.patch ! series From lukas.stadler at jku.at Thu Nov 12 09:05:21 2009 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Thu, 12 Nov 2009 17:05:21 +0000 Subject: hg: mlvm/mlvm/jdk: continuation bugfixes, coroutine prototype Message-ID: <20091112170521.A5E8F414C9@hg.openjdk.java.net> Changeset: c44366606742 Author: lstadler Date: 2009-11-12 17:13 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/c44366606742 continuation bugfixes, coroutine prototype ! callcc.patch From lukas.stadler at jku.at Thu Nov 12 09:08:43 2009 From: lukas.stadler at jku.at (Lukas Stadler) Date: Thu, 12 Nov 2009 18:08:43 +0100 Subject: coroutine support Message-ID: <4AFC411B.7010009@jku.at> Hi everybody! I've just checked in the first prototype of a coroutine implementation. It's implemented using the continuations framework, so it's not very speedy (~1?s per context switch in a simple example) but it allows me to experiment on how the API for coroutines could look like. This is how it currently works: public class CoroutineTest extends Coroutine { public CoroutineTest(CoroutineContext context) { super(context); } public static void main(String[] args) { CoroutineContext context = new CoroutineContext(); new CoroutineTest(context); new CoroutineTest(context); context.start(null); } @Continuable protected Object run(Object value) { for (int i = 0; i < 10; i++) { System.out.println(i); yield(null); } return null; } } The Coroutine class is very similar to the thread class, it can either be subclassed or provided with a CoRunnable object. The main concept is that every coroutine is associated with a CoroutineContext when it is created. The coroutines will start to execute as soon as CoroutineContext.start is called and this method will not return unless all coroutines have finished. The coroutines are kept in a doubly-linked ring and the default scheduling (which can be changed by subclassing CoroutineContext) always just yields to the next coroutine in the ring. The main drawback of using a coroutine context in this way is of course that coroutines are tied to a specific thread - is this a problem? A notion of "moving" a coroutine from one context (and thread) to another could be introduced, but a coroutine will always need to be associated with a context so that we can make sure it will end properly. I'd be glad to hear what you guys think of this! cheers Lukas From headius at headius.com Thu Nov 12 09:56:49 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 12 Nov 2009 11:56:49 -0600 Subject: coroutine support In-Reply-To: <4AFC411B.7010009@jku.at> References: <4AFC411B.7010009@jku.at> Message-ID: Hot diggity! On Thu, Nov 12, 2009 at 11:08 AM, Lukas Stadler wrote: > Hi everybody! > > I've just checked in the first prototype of a coroutine implementation. > It's implemented using the continuations framework, so it's not very > speedy (~1?s per context switch in a simple example) but it allows me to > experiment on how the API for coroutines could look like. > This is how it currently works: > > public class CoroutineTest extends Coroutine { > ? ?public CoroutineTest(CoroutineContext context) { > ? ? ? ?super(context); > ? ?} > > ? ?public static void main(String[] args) { > ? ? ? ?CoroutineContext context = new CoroutineContext(); > ? ? ? ?new CoroutineTest(context); > ? ? ? ?new CoroutineTest(context); > ? ? ? ?context.start(null); > ? ?} > > ? ?@Continuable > ? ?protected Object run(Object value) { > ? ? ? ?for (int i = 0; i < 10; i++) { > ? ? ? ? ? ?System.out.println(i); > ? ? ? ? ? ?yield(null); > ? ? ? ?} > ? ? ? ?return null; > ? ?} > } Looks pretty clean to me! I assume there's an equivalent "resume" called from outside to pick up where the previous yield left off, yes? > The Coroutine class is very similar to the thread class, it can either > be subclassed or provided with a CoRunnable object. > The main concept is that every coroutine is associated with a > CoroutineContext when it is created. The coroutines will start to > execute as soon as CoroutineContext.start is called and this method will > not return unless all coroutines have finished. The coroutines are kept > in a doubly-linked ring and the default scheduling (which can be changed > by subclassing CoroutineContext) always just yields to the next > coroutine in the ring. Interesting. I guess I don't know this use case for coroutines. The cases I need would (I believe) all be isolated CoroutineContexts that may or may not call against each other. > The main drawback of using a coroutine context in this way is of course > that coroutines are tied to a specific thread - is this a problem? A > notion of "moving" a coroutine from one context (and thread) to another > could be introduced, but a coroutine will always need to be associated > with a context so that we can make sure it will end properly. > I'd be glad to hear what you guys think of this! I'm excited to try it out! Tying to a specific thread should not be a problem for me...I forgot what the outcome of our long coroutine discussion was, but if I remember correctly tying to a thread was considered one of the safer (if more limited) ways to go. And in JRuby, there should be no cases where we need to use coroutines across threads since Ruby itself won't do that. Does the patch apply and build and all right now? I could try playing with it today. - Charlie From headius at headius.com Thu Nov 12 10:44:34 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 12 Nov 2009 12:44:34 -0600 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> Message-ID: Right now I'm getting two failed patches when trying guards="buildable callcc". The first is applying callcc to hotspot: applying callcc.patch patching file src/cpu/x86/vm/templateInterpreter_x86_32.cpp Hunk #1 succeeded at 160 with fuzz 1 (offset -8 lines). patching file src/share/vm/classfile/vmSymbols.hpp Hunk #1 FAILED at 347 1 out of 6 hunks FAILED -- saving rejects to file src/share/vm/classfile/vmSymbols.hpp.rej The second is applying indy.tests.patch to jdk: applying indy.tests.patch patching file test/java/dyn/MethodHandlesTest.java Hunk #2 FAILED at 110 1 out of 16 hunks FAILED -- saving rejects to file test/java/dyn/MethodHandlesTest.java.rej I'm going to try callcc alone against bsd-port head. On Thu, Nov 12, 2009 at 11:56 AM, Charles Oliver Nutter wrote: > Hot diggity! > > On Thu, Nov 12, 2009 at 11:08 AM, Lukas Stadler wrote: >> Hi everybody! >> >> I've just checked in the first prototype of a coroutine implementation. >> It's implemented using the continuations framework, so it's not very >> speedy (~1?s per context switch in a simple example) but it allows me to >> experiment on how the API for coroutines could look like. >> This is how it currently works: >> >> public class CoroutineTest extends Coroutine { >> ? ?public CoroutineTest(CoroutineContext context) { >> ? ? ? ?super(context); >> ? ?} >> >> ? ?public static void main(String[] args) { >> ? ? ? ?CoroutineContext context = new CoroutineContext(); >> ? ? ? ?new CoroutineTest(context); >> ? ? ? ?new CoroutineTest(context); >> ? ? ? ?context.start(null); >> ? ?} >> >> ? ?@Continuable >> ? ?protected Object run(Object value) { >> ? ? ? ?for (int i = 0; i < 10; i++) { >> ? ? ? ? ? ?System.out.println(i); >> ? ? ? ? ? ?yield(null); >> ? ? ? ?} >> ? ? ? ?return null; >> ? ?} >> } > > Looks pretty clean to me! I assume there's an equivalent "resume" > called from outside to pick up where the previous yield left off, yes? > >> The Coroutine class is very similar to the thread class, it can either >> be subclassed or provided with a CoRunnable object. >> The main concept is that every coroutine is associated with a >> CoroutineContext when it is created. The coroutines will start to >> execute as soon as CoroutineContext.start is called and this method will >> not return unless all coroutines have finished. The coroutines are kept >> in a doubly-linked ring and the default scheduling (which can be changed >> by subclassing CoroutineContext) always just yields to the next >> coroutine in the ring. > > Interesting. I guess I don't know this use case for coroutines. The > cases I need would (I believe) all be isolated CoroutineContexts that > may or may not call against each other. > >> The main drawback of using a coroutine context in this way is of course >> that coroutines are tied to a specific thread - is this a problem? A >> notion of "moving" a coroutine from one context (and thread) to another >> could be introduced, but a coroutine will always need to be associated >> with a context so that we can make sure it will end properly. >> I'd be glad to hear what you guys think of this! > > I'm excited to try it out! Tying to a specific thread should not be a > problem for me...I forgot what the outcome of our long coroutine > discussion was, but if I remember correctly tying to a thread was > considered one of the safer (if more limited) ways to go. And in > JRuby, there should be no cases where we need to use coroutines across > threads since Ruby itself won't do that. > > Does the patch apply and build and all right now? I could try playing > with it today. > > - Charlie > From John.Rose at Sun.COM Thu Nov 12 10:46:30 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 12 Nov 2009 10:46:30 -0800 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> Message-ID: <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> On Nov 12, 2009, at 10:44 AM, Charles Oliver Nutter wrote: > I'm going to try callcc alone against bsd-port head. Yes; don't build indy into it; it's too much of a moving target to integrate with callcc etc. -- John From headius at headius.com Thu Nov 12 11:08:26 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 12 Nov 2009 13:08:26 -0600 Subject: coroutine support In-Reply-To: <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> Message-ID: On Thu, Nov 12, 2009 at 12:46 PM, John Rose wrote: > On Nov 12, 2009, at 10:44 AM, Charles Oliver Nutter wrote: > >> I'm going to try callcc alone against bsd-port head. > > Yes; don't build indy into it; it's too much of a moving target to integrate with callcc etc. Ok, I got this far into the build: DARWIN_C_SOURCE -c -o activationFrameKlass.o /Users/headius/projects/davinci/sources/hotspot/src/share/vm/oops/activationFrameKlass.cpp cc1plus: warnings being treated as errors /Users/headius/projects/davinci/sources/hotspot/src/share/vm/oops/activationFrameKlass.cpp: In member function 'int activationFrameKlass::do_oop_internal(oopDesc*, OopClosure&)': /Users/headius/projects/davinci/sources/hotspot/src/share/vm/oops/activationFrameKlass.cpp:106: warning: taking address of temporary make[7]: *** [activationFrameKlass.o] Error 1 make[7]: *** Waiting for unfinished jobs.... make[6]: *** [the_vm] Error 2 make[5]: *** [fastdebug] Error 2 make[4]: *** [generic_build2] Error 2 make[3]: *** [fastdebug] Error 2 make[2]: *** [hotspot-build] Error 2 make[1]: *** [generic_debug_build] Error 2 make: *** [build_fastdebug_image] Error 2 This was against the revision the patch repo is synced to, so I'm going to try to build against bsd-port head now. Lukas: What revision of bsd-port should I be trying to apply/build this against? - Charlie From headius at headius.com Thu Nov 12 11:17:38 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 12 Nov 2009 13:17:38 -0600 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> Message-ID: Ok, no dice for me so far. Here's the complete g++ error. I'm really excited to try this out, so please give me some tips :) g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 -DASSERT -DFASTDEBUG -I. -I../generated/adfiles -I../generated/jvmtifiles -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/asm -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/c1 -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/ci -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/classfile -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/code -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/compiler -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/g1 -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/parNew -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/shared -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_interface -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/interpreter -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/libadt -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/memory -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/oops -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/opto -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/prims -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/runtime -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/services -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/utilities -I/Users/headius/projects/davinci/sources/hotspot/src/cpu/x86/vm -I/Users/headius/projects/davinci/sources/hotspot/src/os/bsd/vm -I/Users/headius/projects/davinci/sources/hotspot/src/os_cpu/bsd_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"17.0-b04\"" -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"headius\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-fastdebug-headius_2009_11_12_13_11-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DCOMPILER2 -DCOMPILER1 -fno-rtti -fno-exceptions -pthread -fcheck-new -m32 -march=i586 -mstackrealign -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wconversion -Wsign-compare -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -o activationFrameKlass.o /Users/headius/projects/davinci/sources/hotspot/src/share/vm/oops/activationFrameKlass.cpp cc1plus: warnings being treated as errors /Users/headius/projects/davinci/sources/hotspot/src/share/vm/oops/activationFrameKlass.cpp: In member function 'int activationFrameKlass::do_oop_internal(oopDesc*, OopClosure&)': /Users/headius/projects/davinci/sources/hotspot/src/share/vm/oops/activationFrameKlass.cpp:106: warning: taking address of temporary make[7]: *** [activationFrameKlass.o] Error 1 make[7]: *** Waiting for unfinished jobs.... make[6]: *** [the_vm] Error 2 make[5]: *** [fastdebug] Error 2 make[4]: *** [generic_build2] Error 2 make[3]: *** [fastdebug] Error 2 make[2]: *** [hotspot-build] Error 2 make[1]: *** [generic_debug_build] Error 2 make: *** [build_fastdebug_image] Error 2 From lukas.stadler at jku.at Thu Nov 12 13:17:32 2009 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Thu, 12 Nov 2009 21:17:32 +0000 Subject: hg: mlvm/mlvm/hotspot: fixed compilation problem: "taking address of temporary" Message-ID: <20091112211732.CD16C41521@hg.openjdk.java.net> Changeset: ecb126590f9d Author: lstadler Date: 2009-11-12 22:16 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ecb126590f9d fixed compilation problem: "taking address of temporary" ! callcc.patch From lukas.stadler at jku.at Thu Nov 12 13:20:27 2009 From: lukas.stadler at jku.at (Lukas Stadler) Date: Thu, 12 Nov 2009 22:20:27 +0100 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> Message-ID: <4AFC7C1B.9070108@jku.at> I fixed that one. I'm compiling with MSVC - I guess I should really switch to another platform... - Lukas Charles Oliver Nutter wrote: > Ok, no dice for me so far. Here's the complete g++ error. I'm really > excited to try this out, so please give me some tips :) From jbaker at zyasoft.com Thu Nov 12 13:41:40 2009 From: jbaker at zyasoft.com (Jim Baker) Date: Thu, 12 Nov 2009 14:41:40 -0700 Subject: coroutine support In-Reply-To: <4AFC411B.7010009@jku.at> References: <4AFC411B.7010009@jku.at> Message-ID: Very cool. We could use this in Jython to support the greenlet model, which would also allow us to implement Stackless Python. Given this, I'm principally interested in the capability of a given coroutine being able to yield to another specified coroutine, as well as being able to describe tree relationships of coroutines (a child's exception should go to its parent). Naively, it would seem like this would be doable through the subclassing you describe. Re being tied to a thread: Standard Python coroutines are not restricted to being run in one thread, however, they cannot be nested either. They are also reasonably performant now, and could be readily made more inline-able with some more engineering. In contrast, the existing implementation of greenlets does require being tied to a thread. If relaxing this in your new work imposes greater overhead, it's probably not worth doing. - Jim On Thu, Nov 12, 2009 at 10:08 AM, Lukas Stadler wrote: > Hi everybody! > > I've just checked in the first prototype of a coroutine implementation. > It's implemented using the continuations framework, so it's not very > speedy (~1?s per context switch in a simple example) but it allows me to > experiment on how the API for coroutines could look like. > This is how it currently works: > > public class CoroutineTest extends Coroutine { > public CoroutineTest(CoroutineContext context) { > super(context); > } > > public static void main(String[] args) { > CoroutineContext context = new CoroutineContext(); > new CoroutineTest(context); > new CoroutineTest(context); > context.start(null); > } > > @Continuable > protected Object run(Object value) { > for (int i = 0; i < 10; i++) { > System.out.println(i); > yield(null); > } > return null; > } > } > > The Coroutine class is very similar to the thread class, it can either > be subclassed or provided with a CoRunnable object. > The main concept is that every coroutine is associated with a > CoroutineContext when it is created. The coroutines will start to > execute as soon as CoroutineContext.start is called and this method will > not return unless all coroutines have finished. The coroutines are kept > in a doubly-linked ring and the default scheduling (which can be changed > by subclassing CoroutineContext) always just yields to the next > coroutine in the ring. > The main drawback of using a coroutine context in this way is of course > that coroutines are tied to a specific thread - is this a problem? A > notion of "moving" a coroutine from one context (and thread) to another > could be introduced, but a coroutine will always need to be associated > with a context so that we can make sure it will end properly. > I'd be glad to hear what you guys think of this! > > cheers > Lukas > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Jim Baker jbaker at zyasoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091112/f9aa61bd/attachment.html From headius at headius.com Thu Nov 12 14:45:00 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 12 Nov 2009 16:45:00 -0600 Subject: coroutine support In-Reply-To: <4AFC7C1B.9070108@jku.at> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> Message-ID: On Thu, Nov 12, 2009 at 3:20 PM, Lukas Stadler wrote: > I fixed that one. I'm compiling with MSVC - I guess I should really > switch to another platform... No doubt :) I got farther, but then this is the result: g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 -DASSERT -DFASTDEBUG -I. -I../generated/adfiles -I../generated/jvmtifiles -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/asm -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/c1 -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/ci -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/classfile -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/code -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/compiler -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/g1 -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/parNew -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/shared -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_interface -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/interpreter -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/libadt -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/memory -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/oops -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/opto -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/prims -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/runtime -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/services -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/utilities -I/Users/headius/projects/davinci/sources/hotspot/src/cpu/x86/vm -I/Users/headius/projects/davinci/sources/hotspot/src/os/bsd/vm -I/Users/headius/projects/davinci/sources/hotspot/src/os_cpu/bsd_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"17.0-b04\"" -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"headius\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-fastdebug-headius_2009_11_12_16_34-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m32 -march=i586 -mstackrealign -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wconversion -Wsign-compare -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -o annotationParser.o /Users/headius/projects/davinci/sources/hotspot/src/share/vm/runtime/annotationParser.cpp cc1plus: warnings being treated as errors /Users/headius/projects/davinci/sources/hotspot/src/share/vm/runtime/annotationParser.hpp: In member function 'constantTag AnnotationParser::get_tag(int)': /Users/headius/projects/davinci/sources/hotspot/src/share/vm/runtime/annotationParser.hpp:127: warning: comparison is always false due to limited range of data type Compiling /Users/headius/projects/davinci/sources/hotspot/src/share/vm/runtime/aprofiler.cpp rm -f aprofiler.o g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 -DASSERT -DFASTDEBUG -I. -I../generated/adfiles -I../generated/jvmtifiles -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/asm -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/c1 -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/ci -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/classfile -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/code -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/compiler -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/g1 -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/parNew -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_implementation/shared -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/gc_interface -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/interpreter -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/libadt -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/memory -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/oops -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/opto -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/prims -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/runtime -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/services -I/Users/headius/projects/davinci/sources/hotspot/src/share/vm/utilities -I/Users/headius/projects/davinci/sources/hotspot/src/cpu/x86/vm -I/Users/headius/projects/davinci/sources/hotspot/src/os/bsd/vm -I/Users/headius/projects/davinci/sources/hotspot/src/os_cpu/bsd_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"17.0-b04\"" -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"headius\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-fastdebug-headius_2009_11_12_16_34-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m32 -march=i586 -mstackrealign -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wconversion -Wsign-compare -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -o aprofiler.o /Users/headius/projects/davinci/sources/hotspot/src/share/vm/runtime/aprofiler.cpp make[7]: *** [annotationParser.o] Error 1 make[7]: *** Waiting for unfinished jobs.... make[6]: *** [the_vm] Error 2 make[5]: *** [fastdebug] Error 2 make[4]: *** [generic_build2] Error 2 make[3]: *** [fastdebug] Error 2 make[2]: *** [hotspot-build] Error 2 make[1]: *** [generic_debug_build] Error 2 make: *** [build_fastdebug_image] Error 2 - Charlie From lukas.stadler at jku.at Thu Nov 12 16:30:44 2009 From: lukas.stadler at jku.at (Lukas Stadler) Date: Fri, 13 Nov 2009 01:30:44 +0100 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> Message-ID: <4AFCA8B4.2040906@jku.at> Charles Oliver Nutter schrieb: > On Thu, Nov 12, 2009 at 3:20 PM, Lukas Stadler wrote: > >> I fixed that one. I'm compiling with MSVC - I guess I should really >> switch to another platform... >> > > No doubt :) > > I got farther, but then this is the result: > It's quite clearly no use fixing those one at a time - I'll build with gcc tomorrow and let you know as soon as it works. - Lukas From headius at headius.com Thu Nov 12 21:32:58 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Thu, 12 Nov 2009 23:32:58 -0600 Subject: coroutine support In-Reply-To: <4AFCA8B4.2040906@jku.at> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> <4AFCA8B4.2040906@jku.at> Message-ID: On Thu, Nov 12, 2009 at 6:30 PM, Lukas Stadler wrote: > It's quite clearly no use fixing those one at a time - I'll build with > gcc tomorrow and let you know as soon as it works. Ok, great, I'll stand by. I can have JRuby's coroutines (and maybe continuations) using your stuff within a day or two once this builds and runs. - Charlie From jin.phd at gmail.com Thu Nov 12 22:16:16 2009 From: jin.phd at gmail.com (Jin Mingjian) Date: Fri, 13 Nov 2009 14:16:16 +0800 Subject: coroutine support In-Reply-To: <4AFC411B.7010009@jku.at> References: <4AFC411B.7010009@jku.at> Message-ID: <795657be0911122216i71eccf48v5cd33ddf2488082e@mail.gmail.com> great news:) I've done some similar helloworld coroutine tests using Javaflow several months ago. It seems that the scheduling time unit of native thread is in the level of ms(although I am not very sure this^_^) 2009/11/13 Lukas Stadler > Hi everybody! > > I've just checked in the first prototype of a coroutine implementation. > It's implemented using the continuations framework, so it's not very > speedy (~1?s per context switch in a simple example) but it allows me to > experiment on how the API for coroutines could look like. > This is how it currently works: > > public class CoroutineTest extends Coroutine { > public CoroutineTest(CoroutineContext context) { > super(context); > } > > public static void main(String[] args) { > CoroutineContext context = new CoroutineContext(); > new CoroutineTest(context); > new CoroutineTest(context); > context.start(null); > } > > @Continuable > protected Object run(Object value) { > for (int i = 0; i < 10; i++) { > System.out.println(i); > yield(null); > } > return null; > } > } > > The Coroutine class is very similar to the thread class, it can either > be subclassed or provided with a CoRunnable object. > The main concept is that every coroutine is associated with a > CoroutineContext when it is created. The coroutines will start to > execute as soon as CoroutineContext.start is called and this method will > not return unless all coroutines have finished. The coroutines are kept > in a doubly-linked ring and the default scheduling (which can be changed > by subclassing CoroutineContext) always just yields to the next > coroutine in the ring. > The main drawback of using a coroutine context in this way is of course > that coroutines are tied to a specific thread - is this a problem? A > notion of "moving" a coroutine from one context (and thread) to another > could be introduced, but a coroutine will always need to be associated > with a context so that we can make sure it will end properly. > I'd be glad to hear what you guys think of this! > > cheers > Lukas > _______________________________________________ > 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/20091113/3f3c1e39/attachment-0001.html From lukas.stadler at jku.at Fri Nov 13 08:38:12 2009 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Fri, 13 Nov 2009 16:38:12 +0000 Subject: hg: mlvm/mlvm/hotspot: fixed more gcc compile problems Message-ID: <20091113163814.9F0D0416BB@hg.openjdk.java.net> Changeset: d0b585dd77a1 Author: lstadler Date: 2009-11-13 17:35 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d0b585dd77a1 fixed more gcc compile problems ! callcc.patch From lukas.stadler at jku.at Fri Nov 13 08:43:26 2009 From: lukas.stadler at jku.at (Lukas Stadler) Date: Fri, 13 Nov 2009 17:43:26 +0100 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> <4AFCA8B4.2040906@jku.at> Message-ID: <4AFD8CAE.5090002@jku.at> I've fixed a few additional compile problems, on a linux machine with gcc 4.4.1 - unfortunately I have no easy access to a mac os machine. I hope that this takes care of your compilation problems. If not - can you please let me know which version of gcc you're using? - Lukas Charles Oliver Nutter wrote: > On Thu, Nov 12, 2009 at 6:30 PM, Lukas Stadler wrote: > >> It's quite clearly no use fixing those one at a time - I'll build with >> gcc tomorrow and let you know as soon as it works. >> > > Ok, great, I'll stand by. I can have JRuby's coroutines (and maybe > continuations) using your stuff within a day or two once this builds > and runs. > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From blackdrag at gmx.org Fri Nov 13 09:09:56 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 13 Nov 2009 18:09:56 +0100 Subject: coroutine support In-Reply-To: <4AFC411B.7010009@jku.at> References: <4AFC411B.7010009@jku.at> Message-ID: <4AFD92E4.5010404@gmx.org> Lukas Stadler schrieb: > Hi everybody! > > I've just checked in the first prototype of a coroutine implementation. > It's implemented using the continuations framework, so it's not very > speedy (~1?s per context switch in a simple example) but it allows me to > experiment on how the API for coroutines could look like. > This is how it currently works: > > public class CoroutineTest extends Coroutine { > public CoroutineTest(CoroutineContext context) { > super(context); > } > > public static void main(String[] args) { > CoroutineContext context = new CoroutineContext(); > new CoroutineTest(context); > new CoroutineTest(context); > context.start(null); > } > > @Continuable > protected Object run(Object value) { > for (int i = 0; i < 10; i++) { > System.out.println(i); > yield(null); > } > return null; > } > } the alternative would be to generate for run something like: private Object run$co(Context context) { l0: switch (context.jumpToLabel) { case 1: jmp l1 } context.l0=0; for (;context.l0<10; context.l0++) { System.out.println(context.l0); l1: context.jumpToLabel=1; return null; } context.jumpToLabel=-1; return null; } jumpToLabel is used to identify the entry/exit point, context will hold all local variables (l*) Where would such an approach be not as good as yours? bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From headius at headius.com Fri Nov 13 09:21:23 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 13 Nov 2009 11:21:23 -0600 Subject: coroutine support In-Reply-To: <4AFD92E4.5010404@gmx.org> References: <4AFC411B.7010009@jku.at> <4AFD92E4.5010404@gmx.org> Message-ID: On Fri, Nov 13, 2009 at 11:09 AM, Jochen Theodorou wrote: > the alternative would be to generate for run something like: > > private Object run$co(Context context) { > ? l0: > ? switch (context.jumpToLabel) { > ? ? ?case 1: jmp l1 > ? } > ? context.l0=0; > ? for (;context.l0<10; context.l0++) { > ? ? System.out.println(context.l0); > ? ? l1: > ? ? context.jumpToLabel=1; > ? ? return null; > ? } > ? context.jumpToLabel=-1; > ? return null; > } > > jumpToLabel is used to identify the entry/exit point, context will hold > all local variables (l*) > > Where would such an approach be not as good as yours? This is basically what all the bytecode-weaving coroutine/continuation libraries do. Jython also does this for their lambda/generator/coroutine stuff so they can jump in and out. The primary issue is that you can only jump in and out of the methods you have performed this transformation on. That means you can't call through any untransformed code and expect to be able to resume it. This is exactly the problem we face in JRuby, where coroutines could have arbitrarily complex call stacks attached to them, across multiple layers of logic, potentially through code we do not control or can't/won't modify in this way. Here's a simple example: class MyList def each [1,2,3].each {|i| yield i} end end enum = MyList.each enum.next enum.next enum.next The "each" in this code does a second internal iteration over a normal Ruby Array, yielding each of its items in turn. But because we're using the "next" method on Enumerator, this acts like a generator, with yield returning control to the caller of "next" after each item. In order to resume the array iteration when "next" is called again, we would have to make all of the following resumable: * The MyList#each method itself * Array#each * The block passed to Array#each * All call logic and protocols for methods and blocks So even for this simple example, the switch-based approach falls down immediately. Full coroutine support means we can just bounce in and out of that stack without having to manipulate any bytecode at all, even across code we don't control. - Charlie From headius at headius.com Fri Nov 13 09:26:54 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 13 Nov 2009 11:26:54 -0600 Subject: coroutine support In-Reply-To: <4AFD8CAE.5090002@jku.at> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> <4AFCA8B4.2040906@jku.at> <4AFD8CAE.5090002@jku.at> Message-ID: On Fri, Nov 13, 2009 at 10:43 AM, Lukas Stadler wrote: > I've fixed a few additional compile problems, on a linux machine with > gcc 4.4.1 - unfortunately I have no easy access to a mac os machine. > I hope that this takes care of your compilation problems. If not - can > you please let me know which version of gcc you're using? > - Lukas No problem...I'm giving it a shot as we speak. I bet this will get us a lot closer, but I will let you know if I see any further issues. - Charlie From blackdrag at gmx.org Fri Nov 13 09:27:56 2009 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 13 Nov 2009 18:27:56 +0100 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> <4AFD92E4.5010404@gmx.org> Message-ID: <4AFD971C.80809@gmx.org> Charles Oliver Nutter schrieb: > On Fri, Nov 13, 2009 at 11:09 AM, Jochen Theodorou wrote: >> the alternative would be to generate for run something like: >> >> private Object run$co(Context context) { >> l0: >> switch (context.jumpToLabel) { >> case 1: jmp l1 >> } >> context.l0=0; >> for (;context.l0<10; context.l0++) { >> System.out.println(context.l0); >> l1: >> context.jumpToLabel=1; >> return null; >> } >> context.jumpToLabel=-1; >> return null; >> } >> >> jumpToLabel is used to identify the entry/exit point, context will hold >> all local variables (l*) >> >> Where would such an approach be not as good as yours? > > This is basically what all the bytecode-weaving coroutine/continuation > libraries do. Jython also does this for their > lambda/generator/coroutine stuff so they can jump in and out. The > primary issue is that you can only jump in and out of the methods you > have performed this transformation on. That means you can't call > through any untransformed code and expect to be able to resume it. but isn't here yield responsible for that? Does this means the coroutine support here will allow calling yield from outside or from deep down the stack? It will it mean the stack will be kept? This was not clear from the first post. Since only one Thread is used I assumed it might not be the case. bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From forax at univ-mlv.fr Fri Nov 13 09:52:14 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 13 Nov 2009 18:52:14 +0100 Subject: coroutine support In-Reply-To: <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> Message-ID: <4AFD9CCE.4030705@univ-mlv.fr> Le 12/11/2009 19:46, John Rose a ?crit : > On Nov 12, 2009, at 10:44 AM, Charles Oliver Nutter wrote: > > >> I'm going to try callcc alone against bsd-port head. >> > Yes; don't build indy into it; it's too much of a moving target to integrate with callcc etc. > It seems currently indy don't build at all. > -- John > R?mi From headius at headius.com Fri Nov 13 09:48:55 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 13 Nov 2009 11:48:55 -0600 Subject: coroutine support In-Reply-To: <4AFD971C.80809@gmx.org> References: <4AFC411B.7010009@jku.at> <4AFD92E4.5010404@gmx.org> <4AFD971C.80809@gmx.org> Message-ID: On Fri, Nov 13, 2009 at 11:27 AM, Jochen Theodorou wrote: > Charles Oliver Nutter schrieb: >> This is basically what all the bytecode-weaving coroutine/continuation >> libraries do. Jython also does this for their >> lambda/generator/coroutine stuff so they can jump in and out. The >> primary issue is that you can only jump in and out of the methods you >> have performed this transformation on. That means you can't call >> through any untransformed code and expect to be able to resume it. > > but isn't here yield responsible for that? Does this means the coroutine > support here will allow calling yield from outside or from deep down the > stack? It will it mean the stack will be kept? This was not clear from > the first post. Since only one Thread is used I assumed it might not be > the case. Here's the Java stack leading up to the yield call in my previous example: at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:106) at ruby.__dash_e__.block_0$RUBY$__block__(-e:1) at ruby.__dash_e__BlockCallback$block_0$RUBY$__block__xx1.call(Unknown Source) at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:105) at org.jruby.runtime.Block.yield(Block.java:194) at org.jruby.RubyArray.eachCommon(RubyArray.java:1611) at org.jruby.RubyArray.each(RubyArray.java:1618) at org.jruby.RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$each.call(org/jruby/RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$each.gen) at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:299) at org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:117) at org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:132) at ruby.__dash_e__.method__1$RUBY$each(-e:1) at ruby.__dash_e__Invokermethod__1$RUBY$eachFixed0.call(__dash_e__#each) at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:299) at org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:117) at org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:132) at ruby.__dash_e__.__file__(-e:1) All of this would have to be instrumented to be resumable. Basically an impossible task. Here's another way to explain it that: what if your calls require reflection, as most in Groovy do? You can't make a reflective call resumable, so you're stuck. - Charlie From jbaker at zyasoft.com Fri Nov 13 10:00:09 2009 From: jbaker at zyasoft.com (Jim Baker) Date: Fri, 13 Nov 2009 11:00:09 -0700 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> <4AFD92E4.5010404@gmx.org> <4AFD971C.80809@gmx.org> Message-ID: On Fri, Nov 13, 2009 at 10:48 AM, Charles Oliver Nutter wrote: > On Fri, Nov 13, 2009 at 11:27 AM, Jochen Theodorou > wrote: > > Charles Oliver Nutter schrieb: > >> This is basically what all the bytecode-weaving coroutine/continuation > >> libraries do. Jython also does this for their > >> lambda/generator/coroutine stuff so they can jump in and out. > Except for the lambda part, this is correct. (Our lambdas are very simple, they're just compiled to construct a function object wrapping that chunk of code.) Because yield is a keyword in Python, it's very easy to do too. > >> The > >> primary issue is that you can only jump in and out of the methods you > >> have performed this transformation on. That means you can't call > >> through any untransformed code and expect to be able to resume it. > > > > but isn't here yield responsible for that? Does this means the coroutine > > support here will allow calling yield from outside or from deep down the > > stack? It will it mean the stack will be kept? This was not clear from > > the first post. Since only one Thread is used I assumed it might not be > > the case. > > Here's the Java stack leading up to the yield call in my previous example: > > at > org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:106) > at ruby.__dash_e__.block_0$RUBY$__block__(-e:1) > at > ruby.__dash_e__BlockCallback$block_0$RUBY$__block__xx1.call(Unknown Source) > at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:105) > at org.jruby.runtime.Block.yield(Block.java:194) > at org.jruby.RubyArray.eachCommon(RubyArray.java:1611) > at org.jruby.RubyArray.each(RubyArray.java:1618) > at > org.jruby.RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$each.call(org/jruby/RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$each.gen) > at > org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:299) > at > org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:117) > at > org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:132) > at ruby.__dash_e__.method__1$RUBY$each(-e:1) > at > ruby.__dash_e__Invokermethod__1$RUBY$eachFixed0.call(__dash_e__#each) > at > org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:299) > at > org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:117) > at > org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:132) > at ruby.__dash_e__.__file__(-e:1) > > All of this would have to be instrumented to be resumable. Basically > an impossible task. > > Likewise with Jython for any nested coroutine usage, as seen in stackless/greenlets. We could implement a trampoline in our experimental Python bytecode VM, but this would be restricted to just any Python code that is compiled to Python bytecode (reweaving artifacts compiled to Java bytecode is too limited for real usage) and forget doing it in Java libraries outside of our control. It might be interesting. But not as useful and general as this new work by Lukas. -- Jim Baker jbaker at zyasoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091113/15c28cd3/attachment-0001.html From headius at headius.com Fri Nov 13 10:05:26 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Fri, 13 Nov 2009 12:05:26 -0600 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> <4AFD92E4.5010404@gmx.org> <4AFD971C.80809@gmx.org> Message-ID: On Fri, Nov 13, 2009 at 12:00 PM, Jim Baker wrote: >> > Charles Oliver Nutter schrieb: >> >> This is basically what all the bytecode-weaving coroutine/continuation >> >> libraries do. Jython also does this for their >> >> lambda/generator/coroutine stuff so they can jump in and out. > > Except for the lambda part, this is correct. (Our lambdas are very simple, > they're just compiled to construct a function object wrapping that chunk of > code.) Because yield is a keyword in Python, it's very easy to do too. Thanks Jim...I can never keep the terms straight for Python :) - Charlie From forax at univ-mlv.fr Fri Nov 13 15:31:10 2009 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Sat, 14 Nov 2009 00:31:10 +0100 Subject: coroutine support In-Reply-To: References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> <4AFCA8B4.2040906@jku.at> <4AFD8CAE.5090002@jku.at> Message-ID: <4AFDEC3E.4040005@univ-mlv.fr> Hi Lukas, hi all, C1 seems to work but not C2 (see further). Furthermore by default, hotspot requires that package javax.stack exists instead of gracefully disable coroutine if javax.stack is not here (which is the case of the first build, i.e when you use jdk6 to compile jdk7). I will test it tomorrow, R?mi g++ -DLINUX -D_GNU_SOURCE -DIA32 -DPRODUCT -I. -I../generated/adfiles -I../generated/jvmtifiles -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/asm -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/c1 -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/ci -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/classfile -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/code -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/compiler -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/gc_implementation -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/gc_implementation/parNew -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/gc_implementation/g1 -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/gc_implementation/shared -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/gc_interface -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/interpreter -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/libadt -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/memory -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/oops -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/opto -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/prims -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/runtime -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/services -I/home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/utilities -I/home/forax/java/workspace/coroutine/sources/hotspot/src/cpu/x86/vm -I/home/forax/java/workspace/coroutine/sources/hotspot/src/os/linux/vm -I/home/forax/java/workspace/coroutine/sources/hotspot/src/os_cpu/linux_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"17.0-b03-internal\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"forax\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -m32 -march=i586 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wsign-compare -c -o compile.o /home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/opto/compile.cpp /home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/opto/compile.cpp: In constructor ?Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool)?: /home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/opto/compile.cpp:681: erreur: no matching function for call to ?ciEnv::register_method(ciMethod*&, int&, CodeOffsets*, int&, CodeBuffer*, int, OopMapSet*&, ExceptionHandlerTable*, ImplicitExceptionTable*, C2Compiler*&, int, bool, bool)? /home/forax/java/workspace/coroutine/sources/hotspot/src/share/vm/ci/ciEnv.hpp:273: note: candidats sont: void ciEnv::register_method(ciMethod*, int, CodeOffsets*, int, CodeBuffer*, int, int, OopMapSet*, ExceptionHandlerTable*, ImplicitExceptionTable*, ContinuationPcTable*, AbstractCompiler*, int, bool, bool) > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From lukas.stadler at jku.at Sat Nov 14 01:22:58 2009 From: lukas.stadler at jku.at (Lukas Stadler) Date: Sat, 14 Nov 2009 10:22:58 +0100 Subject: coroutine support In-Reply-To: <4AFDEC3E.4040005@univ-mlv.fr> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> <4AFCA8B4.2040906@jku.at> <4AFD8CAE.5090002@jku.at> <4AFDEC3E.4040005@univ-mlv.fr> Message-ID: <4AFE76F2.8050100@jku.at> Ah, yes... I forgot to mention: it's currently only implemented in C1, and it doesn't even compile on C2 because I had to extend the compiler interface. But I'll probably get rid of that, and then it will be a lot easier to get C2 working as well. You're of course right about the graceful shutdown - I will do that as well. And if at runtime you're getting crashes in weird places: chances are that -Xcomp will fix it. - Lukas R?mi Forax wrote: > Hi Lukas, hi all, > > C1 seems to work but not C2 (see further). > > Furthermore by default, hotspot requires that package javax.stack exists > instead of gracefully disable coroutine if javax.stack is not here > (which is the case of the first build, i.e when you use jdk6 to compile > jdk7). > > I will test it tomorrow, > R?mi > From forax at univ-mlv.fr Sat Nov 14 10:03:35 2009 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Sat, 14 Nov 2009 19:03:35 +0100 Subject: coroutine support In-Reply-To: <4AFE76F2.8050100@jku.at> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> <4AFCA8B4.2040906@jku.at> <4AFD8CAE.5090002@jku.at> <4AFDEC3E.4040005@univ-mlv.fr> <4AFE76F2.8050100@jku.at> Message-ID: <4AFEF0F7.1030002@univ-mlv.fr> Le 14/11/2009 10:22, Lukas Stadler a ?crit : > Ah, yes... I forgot to mention: it's currently only implemented in C1, > and it doesn't even compile on C2 because I had to extend the compiler > interface. But I'll probably get rid of that, and then it will be a lot > easier to get C2 working as well. > > You're of course right about the graceful shutdown - I will do that as > well. And if at runtime you're getting crashes in weird places: chances > are that -Xcomp will fix it. > > - Lukas > Hi Lukas, Your example doesn't work on my laptop: 0 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (nmethod.cpp:1997), pid=32273, tid=14347120 # Error: guarantee(cont_offset != 0,"unhandled implicit exception in compiled code") # # JRE version: 7.0-b75 # Java VM: OpenJDK Client VM (17.0-b03-internal compiled mode linux-x86 ) # An error report file with more information is saved as: # /home/forax/java/workspace/coroutine-test/hs_err_pid32273.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I've attached the hotspot error log. I've the same error using Fiber or Continuation. R?mi ------------------------------------------------------------------------ public class FiberTest { static class MyFiber extends Fiber { @Override protected Object generate(Object arg) { System.out.println("generate called with "+arg); return null; } } @Continuable public static void main(String[] args) { MyFiber fiber=new MyFiber(); Object result = fiber.resume("toto"); System.out.println("resume output "+result); } } ------------------------------------------------------------------------ public class CoroutineTest extends Coroutine { public CoroutineTest(CoroutineContext context) { super(context); } public static void main(String[] args) { CoroutineContext context = new CoroutineContext(); new CoroutineTest(context); new CoroutineTest(context); context.start(null); } @Continuable protected Object run(Object value) { for (int i = 0; i< 10; i++) { System.out.println(i); yield(null); } return null; } } > R?mi Forax wrote: > >> Hi Lukas, hi all, >> >> C1 seems to work but not C2 (see further). >> >> Furthermore by default, hotspot requires that package javax.stack exists >> instead of gracefully disable coroutine if javax.stack is not here >> (which is the case of the first build, i.e when you use jdk6 to compile >> jdk7). >> >> I will test it tomorrow, >> R?mi >> >> > _______________________________________________ > 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: hs_err_pid32273.log Url: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091114/3046f4a0/attachment.ksh From raffaello.giulietti at gmail.com Mon Nov 16 01:14:14 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 16 Nov 2009 10:14:14 +0100 Subject: mlvm don't build In-Reply-To: <4AEE9A0C.5090101@gmail.com> References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> Message-ID: <4B0117E6.8010302@gmail.com> R?mi, could you find a way out of the problem you reported a couple of weeks ago? I retried without success 10 minutes ago, pulling all the most recent changes from both mercurial repos (bsd-port and mlvm) and following the instructions in patches/README.txt, a procedure that worked some weeks ago. Cheers Raffaello Raffaello Giulietti wrote: > R?mi Forax wrote: >> No way to apply the patch series as is. >> >> + (cd sources/hotspot; hg qpush -a) >> applying snowleopard.patch >> applying meth-6815692.patch >> applying indy-6858164.patch >> applying indy-amd64.patch >> applying meth.walker.patch >> applying indy-cleanup-6893081.patch >> applying indy.compiler.patch >> skipping indy.compiler.inline.patch - guarded by '-testable' >> skipping dynopt.patch - guarded by '-buildable' >> skipping indy-sparc.patch - guarded by '-buildable' >> skipping meth.proj.patch - guarded by ['+projects'] >> skipping anonk.proj.patch - guarded by ['+projects'] >> skipping annot.patch - guarded by '-testable' >> skipping inti.patch - guarded by '-buildable' >> skipping callcc.patch - guarded by '-testable' >> skipping tailc.patch - guarded by ['+tailc-lazy'] >> skipping tailc-eager.patch - guarded by ['+tailc-lazy'] >> skipping hotswap.patch - guarded by ['+hotswap'] >> now at: indy.compiler.patch >> + (cd sources/jdk; hg qpush -a) >> applying regtest-6891770.patch >> applying indy.tests.patch >> patching file test/java/dyn/MethodHandlesTest.java >> Hunk #2 FAILED at 110 >> 1 out of 16 hunks FAILED -- saving rejects to file >> test/java/dyn/MethodHandlesTest.java.rej >> patch failed, unable to continue (try -v) >> patch failed, rejects left in working dir >> errors during apply, please fix and refresh indy.tests.patch >> *** Exit status 2. >> + (cd sources/langtools; hg qpush -a) >> applying meth.patch >> skipping dyncast.patch - guarded by ['+dyncast'] >> skipping tailc.patch - guarded by ['+tailc'] >> now at: meth.patch >> >> indy.tests.patch seems to be the offending patch. >> >> R?mi >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > R?mi, you're not alone! Same issue for me on OpenSolaris 32 bits. > > Raffaello > From forax at univ-mlv.fr Mon Nov 16 01:58:22 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 16 Nov 2009 10:58:22 +0100 Subject: mlvm don't build In-Reply-To: <4B0117E6.8010302@gmail.com> References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> Message-ID: <4B01223E.2020803@univ-mlv.fr> Raffaello Giulietti a ?crit : > R?mi, > > could you find a way out of the problem you reported a couple of weeks ago? > > I retried without success 10 minutes ago, pulling all the most recent > changes from both mercurial repos (bsd-port and mlvm) and following the > instructions in patches/README.txt, a procedure that worked some weeks ago. > > Cheers > Raffaello > Hi Raffaello, indy.test is patch containing JUnit tests, so you can skip it by commenting the patch in file series. But currently the patch queue is not in a state that allow to play with it, because method handle and indy patchs are in the review process in order to be integrated in hotspot main workspace. I think we have to wait the end of the sync with the main workspace before to be able to play again with indy patches. R?mi > > > Raffaello Giulietti wrote: > >> R?mi Forax wrote: >> >>> No way to apply the patch series as is. >>> >>> + (cd sources/hotspot; hg qpush -a) >>> applying snowleopard.patch >>> applying meth-6815692.patch >>> applying indy-6858164.patch >>> applying indy-amd64.patch >>> applying meth.walker.patch >>> applying indy-cleanup-6893081.patch >>> applying indy.compiler.patch >>> skipping indy.compiler.inline.patch - guarded by '-testable' >>> skipping dynopt.patch - guarded by '-buildable' >>> skipping indy-sparc.patch - guarded by '-buildable' >>> skipping meth.proj.patch - guarded by ['+projects'] >>> skipping anonk.proj.patch - guarded by ['+projects'] >>> skipping annot.patch - guarded by '-testable' >>> skipping inti.patch - guarded by '-buildable' >>> skipping callcc.patch - guarded by '-testable' >>> skipping tailc.patch - guarded by ['+tailc-lazy'] >>> skipping tailc-eager.patch - guarded by ['+tailc-lazy'] >>> skipping hotswap.patch - guarded by ['+hotswap'] >>> now at: indy.compiler.patch >>> + (cd sources/jdk; hg qpush -a) >>> applying regtest-6891770.patch >>> applying indy.tests.patch >>> patching file test/java/dyn/MethodHandlesTest.java >>> Hunk #2 FAILED at 110 >>> 1 out of 16 hunks FAILED -- saving rejects to file >>> test/java/dyn/MethodHandlesTest.java.rej >>> patch failed, unable to continue (try -v) >>> patch failed, rejects left in working dir >>> errors during apply, please fix and refresh indy.tests.patch >>> *** Exit status 2. >>> + (cd sources/langtools; hg qpush -a) >>> applying meth.patch >>> skipping dyncast.patch - guarded by ['+dyncast'] >>> skipping tailc.patch - guarded by ['+tailc'] >>> now at: meth.patch >>> >>> indy.tests.patch seems to be the offending patch. >>> >>> R?mi >>> _______________________________________________ >>> mlvm-dev mailing list >>> mlvm-dev at openjdk.java.net >>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >>> >> R?mi, you're not alone! Same issue for me on OpenSolaris 32 bits. >> >> Raffaello >> >> > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From raffaello.giulietti at gmail.com Mon Nov 16 02:03:20 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 16 Nov 2009 11:03:20 +0100 Subject: mlvm don't build In-Reply-To: <4B01223E.2020803@univ-mlv.fr> References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> Message-ID: <4B012368.4000303@gmail.com> R?mi Forax wrote: > Raffaello Giulietti a ?crit : >> R?mi, >> >> could you find a way out of the problem you reported a couple of weeks ago? >> >> I retried without success 10 minutes ago, pulling all the most recent >> changes from both mercurial repos (bsd-port and mlvm) and following the >> instructions in patches/README.txt, a procedure that worked some weeks ago. >> >> Cheers >> Raffaello >> > Hi Raffaello, > indy.test is patch containing JUnit tests, so you can skip it by > commenting the patch in file series. > > But currently the patch queue is not in a state that allow to play with it, > because method handle and indy patchs are in the review process > in order to be integrated in hotspot main workspace. > I think we have to wait the end of the sync with the main workspace before > to be able to play again with indy patches. > > R?mi > I see. So, let's wait for more stable changesets. Thanks Raffaello From Christian.Thalinger at Sun.COM Mon Nov 16 03:13:52 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 16 Nov 2009 12:13:52 +0100 Subject: mlvm don't build In-Reply-To: <4B012368.4000303@gmail.com> References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> Message-ID: <1258370032.3086.43.camel@macbook> On Mon, 2009-11-16 at 11:03 +0100, Raffaello Giulietti wrote: > > But currently the patch queue is not in a state that allow to play with it, > > because method handle and indy patchs are in the review process > > in order to be integrated in hotspot main workspace. > > I think we have to wait the end of the sync with the main workspace before > > to be able to play again with indy patches. > > > > R?mi > > > > I see. > > So, let's wait for more stable changesets. I hope we get them in soon. But I will have a look at the indy.patch problem. -- Christian From emmanuel.castro at laposte.net Mon Nov 16 07:21:32 2009 From: emmanuel.castro at laposte.net (Emmanuel Castro) Date: Mon, 16 Nov 2009 16:21:32 +0100 Subject: a paper on invokedynamic In-Reply-To: <636798D9-0DAF-4FD6-AEB2-377271E82C9A@sun.com> References: <636798D9-0DAF-4FD6-AEB2-377271E82C9A@sun.com> Message-ID: <736021ac0911160721u28f9720xa23df778aa4c1e56@mail.gmail.com> I am not sure of my English skills, however I noticed a strange sentence : "The four method invocation instructions in the JVM correspond directly to to different kinds of Java method calls". I think there is a "to" in surpus in "to to". Emmanuel CASTRO -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091116/7a63bcd4/attachment.html From raffaello.giulietti at gmail.com Mon Nov 16 07:32:41 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 16 Nov 2009 16:32:41 +0100 Subject: native methods inlining Message-ID: <4B017099.9050200@gmail.com> Not directly related to the mlvm but just for my own curiosity: * Is HotSpot able to inline JNI calls? * If so, what are the prerequisites? * Or are there plans to add this optimization? From Christian.Thalinger at Sun.COM Mon Nov 16 07:39:51 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Mon, 16 Nov 2009 16:39:51 +0100 Subject: native methods inlining In-Reply-To: <4B017099.9050200@gmail.com> References: <4B017099.9050200@gmail.com> Message-ID: <1258385991.3086.89.camel@macbook> On Mon, 2009-11-16 at 16:32 +0100, Raffaello Giulietti wrote: > Not directly related to the mlvm but just for my own curiosity: > > * Is HotSpot able to inline JNI calls? > * If so, what are the prerequisites? > * Or are there plans to add this optimization? C2 (not sure about C1) can inline (intrinsify) a couple of JNI methods from the core library, like e.g. Class.getSuperclass(). But if you mean whether it can inline JNI methods you wrote, than the answer is no. -- Christian From raffaello.giulietti at gmail.com Mon Nov 16 07:55:10 2009 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 16 Nov 2009 16:55:10 +0100 Subject: native methods inlining In-Reply-To: <1258385991.3086.89.camel@macbook> References: <4B017099.9050200@gmail.com> <1258385991.3086.89.camel@macbook> Message-ID: <4B0175DE.2000609@gmail.com> Christian Thalinger wrote: > On Mon, 2009-11-16 at 16:32 +0100, Raffaello Giulietti wrote: >> Not directly related to the mlvm but just for my own curiosity: >> >> * Is HotSpot able to inline JNI calls? >> * If so, what are the prerequisites? >> * Or are there plans to add this optimization? > > C2 (not sure about C1) can inline (intrinsify) a couple of JNI methods > from the core library, like e.g. Class.getSuperclass(). > > But if you mean whether it can inline JNI methods you wrote, than the > answer is no. > > -- Christian > In fact I didn't meant intrinsics, but general native methods simple enough to be inlined, at least conceptually. If I remember well, there were some experiments at IBM/University of Toronto in this topic: that's why I wondered about HotSpot. Perhaps for another life... From John.Rose at Sun.COM Mon Nov 16 14:54:46 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 16 Nov 2009 14:54:46 -0800 Subject: a paper on invokedynamic In-Reply-To: <736021ac0911160721u28f9720xa23df778aa4c1e56@mail.gmail.com> References: <636798D9-0DAF-4FD6-AEB2-377271E82C9A@sun.com> <736021ac0911160721u28f9720xa23df778aa4c1e56@mail.gmail.com> Message-ID: <14DE821D-21CF-4B59-853E-502944957D9C@sun.com> On Nov 16, 2009, at 7:21 AM, Emmanuel Castro wrote: > I am not sure of my English skills, however I noticed a strange sentence : > "The four method invocation instructions in the JVM correspond directly to to different kinds of Java method calls". > I think there is a "to" in surpus in "to to". In this case your English skills are clearly superior to mine. Thanks for pointing out the typo! Item (b) in 2.1 also has a missing article "a" in "a symbolic entity". More fundamentally, Dean Long has pointed out that my account in 1. of pre-instruction linkage is oversimplified; the fix is in bold: Member lookup and matching of names and types is performed once only as a symbolic reference is linked, and specifically when it is resolved ([Lindholm99] 5.4.3). This happens before the first time a particular member reference instruction executes. And also in 3.: Like all invoke instructions, invokedynamic can be linked lazily, as late as the first execution of each dynamic call site. And 3.1: Before an unlinked dynamic call site is executed, the JVM calls the site?s bootstrap method. Perhaps I can get these fixes into the final paper. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091116/af8b517c/attachment.html From lukas.stadler at jku.at Thu Nov 19 10:32:06 2009 From: lukas.stadler at jku.at (lukas.stadler at jku.at) Date: Thu, 19 Nov 2009 18:32:06 +0000 Subject: hg: mlvm/mlvm/hotspot: callcc classes optional, works with sp-based get_thread Message-ID: <20091119183207.4E020412C3@hg.openjdk.java.net> Changeset: bac38c946133 Author: lstadler Date: 2009-11-19 18:50 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/bac38c946133 callcc classes optional, works with sp-based get_thread ! callcc.patch From lukas.stadler at jku.at Thu Nov 19 10:32:40 2009 From: lukas.stadler at jku.at (Lukas Stadler) Date: Thu, 19 Nov 2009 19:32:40 +0100 Subject: coroutine support In-Reply-To: <4AFEF0F7.1030002@univ-mlv.fr> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> <4AFCA8B4.2040906@jku.at> <4AFD8CAE.5090002@jku.at> <4AFDEC3E.4040005@univ-mlv.fr> <4AFE76F2.8050100@jku.at> <4AFEF0F7.1030002@univ-mlv.fr> Message-ID: <4B058F48.9070001@jku.at> Hi! R?mi Forax wrote: > Hi Lukas, > Your example doesn't work on my laptop: Ok, after I finally got everything running on Linux+Netbeans so that I can debug into the assembly code I was able to reproduce this. In one place I used Assembler.get_thread without a valid esp, which is totally fine on windows but not-so-good on Linux. > public class FiberTest { > > static class MyFiber extends Fiber { > @Override > protected Object generate(Object arg) { > System.out.println("generate called with "+arg); > > return null; > } > } > ... > } If you want to call "yield" from within the generate method you should make it @Continuable. It should now also run fine without the javax.stack classes. cheers, Lukas From forax at univ-mlv.fr Thu Nov 19 11:09:00 2009 From: forax at univ-mlv.fr (=?windows-1252?Q?R=E9mi_Forax?=) Date: Thu, 19 Nov 2009 20:09:00 +0100 Subject: coroutine support In-Reply-To: <4B058F48.9070001@jku.at> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> <4AFCA8B4.2040906@jku.at> <4AFD8CAE.5090002@jku.at> <4AFDEC3E.4040005@univ-mlv.fr> <4AFE76F2.8050100@jku.at> <4AFEF0F7.1030002@univ-mlv.fr> <4B058F48.9070001@jku.at> Message-ID: <4B0597CC.7050604@univ-mlv.fr> Le 19/11/2009 19:32, Lukas Stadler a ?crit : > Hi! > Hi Lukas, > R?mi Forax wrote: > >> Hi Lukas, >> Your example doesn't work on my laptop: >> > Ok, after I finally got everything running on Linux+Netbeans so that I > can debug into the assembly code I was able to reproduce this. In one > place I used Assembler.get_thread without a valid esp, which is totally > fine on windows but not-so-good on Linux. > Multi-OS dev is always a nightmare, I am glad it's your problem and not mine :) > >> public class FiberTest { >> >> static class MyFiber extends Fiber { >> @Override >> protected Object generate(Object arg) { >> System.out.println("generate called with "+arg); >> >> return null; >> } >> } >> ... >> } >> > If you want to call "yield" from within the generate method you should > make it @Continuable. > Could you re-explain where I have to put annotations and which one ? > It should now also run fine without the javax.stack classes. > Cool. > cheers, > Lukas > regards, R?mi From lukas.stadler at jku.at Thu Nov 19 11:31:17 2009 From: lukas.stadler at jku.at (Lukas Stadler) Date: Thu, 19 Nov 2009 20:31:17 +0100 Subject: coroutine support In-Reply-To: <4B0597CC.7050604@univ-mlv.fr> References: <4AFC411B.7010009@jku.at> <4DC1BD30-2C26-4D64-B9CB-2E255A40EA3C@sun.com> <4AFC7C1B.9070108@jku.at> <4AFCA8B4.2040906@jku.at> <4AFD8CAE.5090002@jku.at> <4AFDEC3E.4040005@univ-mlv.fr> <4AFE76F2.8050100@jku.at> <4AFEF0F7.1030002@univ-mlv.fr> <4B058F48.9070001@jku.at> <4B0597CC.7050604@univ-mlv.fr> Message-ID: <4B059D05.9000502@jku.at> R?mi Forax schrieb: > Could you re-explain where I have to put annotations and which one ? > Of course. If you want to yield a value within generate then the contents of the generate-stackframe need to be stored. In order to allow this it needs to be marked as @Continuable: @Continuable @Override protected Object generate(Object arg) { System.out.println("generate called with "+arg); yield("1"); yield("2"); return null; } If you remove the @Continuable you should get an Exception telling you not to do that. regards, Lukas From john.rose at sun.com Sun Nov 22 16:14:48 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Mon, 23 Nov 2009 00:14:48 +0000 Subject: hg: mlvm/mlvm/langtools: meth, indy: Rebase to jdk7-b76 Message-ID: <20091123001449.E570D418C6@hg.openjdk.java.net> Changeset: a26478eb0f06 Author: jrose Date: 2009-11-22 16:09 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/a26478eb0f06 meth, indy: Rebase to jdk7-b76 ! series From john.rose at sun.com Sun Nov 22 16:15:14 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Mon, 23 Nov 2009 00:15:14 +0000 Subject: hg: mlvm/mlvm/hotspot: meth, indy: Rebase to jdk7-b76 (plus recent bsd-port tweaks) Message-ID: <20091123001514.A6F4A418C7@hg.openjdk.java.net> Changeset: 07b6e3bb8bb9 Author: jrose Date: 2009-11-22 16:09 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/07b6e3bb8bb9 meth, indy: Rebase to jdk7-b76 (plus recent bsd-port tweaks) ! indy-6858164.patch ! indy-cleanup-6893081.patch ! indy.compiler.inline.patch ! meth-6815692.patch + meth.patch ! meth.walker.patch ! series ! snowleopard.patch From forax at univ-mlv.fr Mon Nov 23 01:57:52 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 23 Nov 2009 10:57:52 +0100 Subject: @Continuable Message-ID: <4B0A5CA0.60508@univ-mlv.fr> Hi all, Hi Lukas, I've sucessfully used continuation with non blocking IO, this is really cool. see http://weblogs.java.net/blog/forax/archive/2009/11/22/nio-server-continuation-java But @Continuable seems odd for me. Why method need to be marked @Continuable ? What is the reason ? Is there a problem in the implementation that in order to be solved need to split method in two kinds, continuable or not ? Is it a security reason ? Because @Continuable is required, there is not way to use any external jars or even classes that already exist in the JDK like by example trying to yield in a SAX handler of an XML parser. This limitation seriously limit the usefulness of the current continuation implementation. R?mi From lukas.stadler at jku.at Mon Nov 23 07:03:53 2009 From: lukas.stadler at jku.at (Lukas Stadler) Date: Mon, 23 Nov 2009 16:03:53 +0100 Subject: @Continuable In-Reply-To: <4B0A5CA0.60508@univ-mlv.fr> References: <4B0A5CA0.60508@univ-mlv.fr> Message-ID: <4B0AA459.4070807@jku.at> Hi! R?mi Forax wrote: > Hi all, Hi Lukas, > I've sucessfully used continuation with non blocking IO, this is > really cool. > see > http://weblogs.java.net/blog/forax/archive/2009/11/22/nio-server-continuation-java > I'm very happy to hear that, thanks for putting this on your blog! > But @Continuable seems odd for me. > > Why method need to be marked @Continuable ? > What is the reason ? > Is there a problem in the implementation that in order to be solved need > to split method in two kinds, continuable or not ? > > Is it a security reason ? There is an implementation issue that right now requires the annotation, but removing it is the next thing on my list. So yes, its basically just a security thing. Imagine for example a try-finally block: using generic continuations I can execute the finally block twice, or not at all, ... you get the picture. The programmer writing the method needs to be aware of this. But in the end I think we can loosen this requirement if we restrict the implementation from continuations to coroutines. At the JVM Language Summit it became clear that at least in the short run coroutines are much more useful and much easier to get right. A coroutine will by definition execute the finally block at most once, and if we make sure that all coroutines end properly before terminating a thread we can even make sure that it will be executed exactly once. regards, Lukas From john.rose at sun.com Mon Nov 23 20:02:21 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 24 Nov 2009 04:02:21 +0000 Subject: hg: mlvm/mlvm/jdk: 2 new changesets Message-ID: <20091124040221.F127941A92@hg.openjdk.java.net> Changeset: 3a72fb17f74f Author: jrose Date: 2009-11-22 16:09 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/3a72fb17f74f meth, indy: Rebase to jdk7-b76 (plus recent bsd-port tweaks) ! indy-6858164.patch ! indy.patch ! indy.tests.patch ! regtest-6891770.patch ! series Changeset: cb470b04fea9 Author: jrose Date: 2009-11-23 20:02 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/cb470b04fea9 Merge From john.rose at sun.com Mon Nov 23 20:03:17 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 24 Nov 2009 04:03:17 +0000 Subject: hg: mlvm/mlvm/hotspot: indy: fix return type mismatches for inlined MHs Message-ID: <20091124040317.2EB4741A93@hg.openjdk.java.net> Changeset: ddecd67aa17b Author: jrose Date: 2009-11-23 20:03 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ddecd67aa17b indy: fix return type mismatches for inlined MHs ! indy.compiler.inline.patch From john.rose at sun.com Mon Nov 23 23:59:15 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 24 Nov 2009 07:59:15 +0000 Subject: hg: mlvm/mlvm/hotspot: dynopt: split out inline tuning and disassembler stuff from dynopt Message-ID: <20091124075915.83B4841ADA@hg.openjdk.java.net> Changeset: 5306e31b9e04 Author: jrose Date: 2009-11-23 23:59 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5306e31b9e04 dynopt: split out inline tuning and disassembler stuff from dynopt + disassembler.patch ! dynopt.patch + inlines.patch ! series From stephen.bannasch at deanbrook.org Tue Nov 24 20:29:46 2009 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Tue, 24 Nov 2009 23:29:46 -0500 Subject: mlvm don't build In-Reply-To: <1258370032.3086.43.camel@macbook> References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> Message-ID: >On Mon, 2009-11-16 at 11:03 +0100, Raffaello Giulietti wrote: >> > But currently the patch queue is not in a state that allow to play with it, >> > because method handle and indy patchs are in the review process >> > in order to be integrated in hotspot main workspace. >> > I think we have to wait the end of the sync with the main workspace before >> > to be able to play again with indy patches. >> > >> > R?mi >> > >> >> I see. >> > > So, let's wait for more stable changesets. > I can't build davinci also. Here's the script I am using to update and build: [davinci]$ cat update.sh cd sources hg fpull -u cd ../patches hg fpull -u cd .. bash patches/make/link-patch-dirs.sh sources patches ls -il patches/hotspot/series sources/hotspot/.hg/patches/series export davinci=$(pwd) guards="buildable testable" sh patches/make/each-patch-repo.sh "hg qselect --pop $guards" '$(sh $davinci/patches/make/current-release.sh)' sh patches/make/each-patch-repo.sh "hg qselect; hg qunapplied" sh patches/make/each-patch-repo.sh "hg update -r" '$(sh $davinci/patches/make/current-release.sh)' sh patches/make/each-patch-repo.sh hg qpush -a echo 'run:' echo 'cd sources' echo 'source build_davinci.sh' Errors start showing up here: testable + (cd sources/hotspot; hg update -r $(sh $davinci/patches/make/current-release.sh)) abort: unknown revision 'd6e9dd8952b4'! *** Exit status 255. + (cd sources/jdk; hg update -r $(sh $davinci/patches/make/current-release.sh)) abort: unknown revision 'fcc79b34e0c4'! *** Exit status 255. + (cd sources/langtools; hg update -r $(sh $davinci/patches/make/current-release.sh)) abort: unknown revision 'f2450a4993b7'! *** Exit status 255. + (cd sources/hotspot; hg qpush -a) applying indy-6858164.patch patching file src/share/vm/classfile/systemDictionary.cpp Hunk #3 FAILED at 2412 Hunk #5 FAILED at 2459 2 out of 6 hunks FAILED -- saving rejects to file src/share/vm/classfile/systemDictionary.cpp.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh indy-6858164.patch *** Exit status 2. + (cd sources/jdk; hg qpush -a) applying indy.pack.patch patching file src/share/classes/com/sun/java/util/jar/pack/Code.java Hunk #1 FAILED at 236 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/java/util/jar/pack/Code.java.rej patching file src/share/classes/com/sun/java/util/jar/pack/Constants.java Hunk #1 FAILED at 349 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/java/util/jar/pack/Constants.java.rej patching file src/share/classes/com/sun/java/util/jar/pack/Instruction.java Hunk #1 FAILED at 483 Hunk #2 FAILED at 498 Hunk #3 FAILED at 526 Hunk #4 FAILED at 605 4 out of 4 hunks FAILED -- saving rejects to file src/share/classes/com/sun/java/util/jar/pack/Instruction.java.rej patching file src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java Hunk #1 FAILED at 1329 Hunk #2 FAILED at 1432 2 out of 2 hunks FAILED -- saving rejects to file src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh indy.pack.patch *** Exit status 2. + (cd sources/langtools; hg qpush -a) patch series already fully applied *** Exit status 1. From John.Rose at Sun.COM Tue Nov 24 23:22:54 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 24 Nov 2009 23:22:54 -0800 Subject: mlvm don't build In-Reply-To: References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> Message-ID: I just rebased to the latest bsd-port. This pulled in some of the mlvm changes (meth-6815692.patch) that have now worked their way out into OpenJDK proper. In order to apply these patches, you need to "hg fpull -u" the sources. For example, this will pull d6e9dd8952b4 from bsd-port/hotspot. -------- hg inc comparing with http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot searching for changes no changes found -------- hg log -r d6e9dd8952b4 1120[qparent] d6e9dd8952b4 2009-11-17 08:32 -0500 kurt Add some missing ELF defines that are missing on OpenBSD -------- I see that your script does an fpull, so I'm puzzled why you don't have d6e9dd8952b4 etc. Please try the commands above in your own davinci/hotspot repo, and let me know what happens. -- John On Nov 24, 2009, at 8:29 PM, Stephen Bannasch wrote: >> On Mon, 2009-11-16 at 11:03 +0100, Raffaello Giulietti wrote: >>>> But currently the patch queue is not in a state that allow to play with it, >>>> because method handle and indy patchs are in the review process >>>> in order to be integrated in hotspot main workspace. >>>> I think we have to wait the end of the sync with the main workspace before >>>> to be able to play again with indy patches. >>>> >>>> R?mi >>>> >>> >>> I see. >>> >>> So, let's wait for more stable changesets. >> > > I can't build davinci also. > > Here's the script I am using to update and build: > > [davinci]$ cat update.sh > cd sources > hg fpull -u > cd ../patches > hg fpull -u > cd .. > bash patches/make/link-patch-dirs.sh sources patches > ls -il patches/hotspot/series sources/hotspot/.hg/patches/series > export davinci=$(pwd) guards="buildable testable" > sh patches/make/each-patch-repo.sh "hg qselect --pop $guards" '$(sh $davinci/patches/make/current-release.sh)' > sh patches/make/each-patch-repo.sh "hg qselect; hg qunapplied" > sh patches/make/each-patch-repo.sh "hg update -r" '$(sh $davinci/patches/make/current-release.sh)' > sh patches/make/each-patch-repo.sh hg qpush -a > echo 'run:' > echo 'cd sources' > echo 'source build_davinci.sh' > > Errors start showing up here: > > testable > + (cd sources/hotspot; hg update -r $(sh $davinci/patches/make/current-release.sh)) > abort: unknown revision 'd6e9dd8952b4'! > *** Exit status 255. > + (cd sources/jdk; hg update -r $(sh $davinci/patches/make/current-release.sh)) > abort: unknown revision 'fcc79b34e0c4'! > *** Exit status 255. > + (cd sources/langtools; hg update -r $(sh $davinci/patches/make/current-release.sh)) > abort: unknown revision 'f2450a4993b7'! > *** Exit status 255. > + (cd sources/hotspot; hg qpush -a) > applying indy-6858164.patch > patching file src/share/vm/classfile/systemDictionary.cpp > Hunk #3 FAILED at 2412 > Hunk #5 FAILED at 2459 > 2 out of 6 hunks FAILED -- saving rejects to file src/share/vm/classfile/systemDictionary.cpp.rej > patch failed, unable to continue (try -v) > patch failed, rejects left in working dir > errors during apply, please fix and refresh indy-6858164.patch > *** Exit status 2. > + (cd sources/jdk; hg qpush -a) > applying indy.pack.patch > patching file src/share/classes/com/sun/java/util/jar/pack/Code.java > Hunk #1 FAILED at 236 > 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/java/util/jar/pack/Code.java.rej > patching file src/share/classes/com/sun/java/util/jar/pack/Constants.java > Hunk #1 FAILED at 349 > 1 out of 1 hunks FAILED -- saving rejects to file src/share/classes/com/sun/java/util/jar/pack/Constants.java.rej > patching file src/share/classes/com/sun/java/util/jar/pack/Instruction.java > Hunk #1 FAILED at 483 > Hunk #2 FAILED at 498 > Hunk #3 FAILED at 526 > Hunk #4 FAILED at 605 > 4 out of 4 hunks FAILED -- saving rejects to file src/share/classes/com/sun/java/util/jar/pack/Instruction.java.rej > patching file src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java > Hunk #1 FAILED at 1329 > Hunk #2 FAILED at 1432 > 2 out of 2 hunks FAILED -- saving rejects to file src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java.rej > patch failed, unable to continue (try -v) > patch failed, rejects left in working dir > errors during apply, please fix and refresh indy.pack.patch > *** Exit status 2. > + (cd sources/langtools; hg qpush -a) > patch series already fully applied > *** Exit status 1. > > _______________________________________________ > 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/20091124/eea573f1/attachment.html From Christian.Thalinger at Sun.COM Wed Nov 25 05:23:36 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 25 Nov 2009 14:23:36 +0100 Subject: mlvm don't build In-Reply-To: References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> Message-ID: <1259155416.894.9.camel@macbook> On Tue, 2009-11-24 at 23:29 -0500, Stephen Bannasch wrote: > >On Mon, 2009-11-16 at 11:03 +0100, Raffaello Giulietti wrote: > >> > But currently the patch queue is not in a state that allow to play with it, > >> > because method handle and indy patchs are in the review process > >> > in order to be integrated in hotspot main workspace. > >> > I think we have to wait the end of the sync with the main workspace before > >> > to be able to play again with indy patches. > >> > > >> > R?mi > >> > > >> > >> I see. > >> > > > So, let's wait for more stable changesets. > > > > I can't build davinci also. I just did a clean build with current bsd-port and mlvm patches. No problems. -- Christian From stephen.bannasch at deanbrook.org Wed Nov 25 08:47:04 2009 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 25 Nov 2009 11:47:04 -0500 Subject: mlvm don't build In-Reply-To: <1259155416.894.9.camel@macbook> References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> <1259155416.894.9.camel@macbook> Message-ID: >On Tue, 2009-11-24 at 23:29 -0500, Stephen Bannasch wrote: >> >On Mon, 2009-11-16 at 11:03 +0100, Raffaello Giulietti wrote: >> >> > But currently the patch queue is not in a state that allow to play with it, >> >> > because method handle and indy patchs are in the review process >> >> > in order to be integrated in hotspot main workspace. >> >> > I think we have to wait the end of the sync with the main workspace before >> >> > to be able to play again with indy patches. >> >> > >> >> > R?mi >> >> > >> >> >> >> I see. >> >> >> > > So, let's wait for more stable changesets. >> > >> >> I can't build davinci also. > >I just did a clean build with current bsd-port and mlvm patches. No >problems. I'n new at using hg ... when I ran hg fpull -u in the root of my bsd-port dir many directories report as unchanged but these three reported that they were skipped: [hotspot] skipped: 'hotspot' has mq patches applied [jdk] skipped: 'jdk' has mq patches applied [langtools] skipped: 'langtools' has mq patches applied It seems like the current state of my repo is blocking needed updates. What are the mq patches? What's the best way to bring my local hg repos back to a state where hg fpull -u will pull in and apply the patches I need? Thanks From stephen.bannasch at deanbrook.org Wed Nov 25 09:03:04 2009 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 25 Nov 2009 12:03:04 -0500 Subject: mlvm don't build In-Reply-To: References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> <1259155416.894.9.camel@macbook> Message-ID: At 11:47 AM -0500 11/25/09, Stephen Bannasch wrote: >What's the best way to bring my local hg repos back to a state where hg fpull -u will pull in and apply the patches I need? Referring to the bsd-ports dir I meant changesets not patches. FYI: more information about my update process (which isn't working yet): Assumming the root of the bsd-port tress is in the dir sources/ and the mlvm patches are in patches/ this is how I start anupdate now: cd sources hg fpull -u cd ../patches hg fpull -u cd .. Which I then follow with bash patches/make/link-patch-dirs.sh sources patches ls -il patches/hotspot/series sources/hotspot/.hg/patches/series export davinci=$(pwd) guards="buildable testable" sh patches/make/each-patch-repo.sh "hg qselect --pop $guards" '$(sh $davinci/patches/make/current-release.sh)' sh patches/make/each-patch-repo.sh "hg qselect; hg qunapplied" sh patches/make/each-patch-repo.sh "hg update -r" '$(sh $davinci/patches/make/current-release.sh)' sh patches/make/each-patch-repo.sh hg qpush -a echo 'run:' echo 'cd sources' echo 'source build_davinci.sh' My build_davinci.sh script looks like this: export LC_ALL=C export LANG=C unset CLASSPATH unset JAVA_HOME sets=" ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3/ ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib ALT_JIBX_LIBS_PATH=/Users/stephen/dev/java/jibx/lib ANT_HOME=/usr/share/ant NO_DOCS=true HOTSPOT_BUILD_JOBS=3 BUILD_LANGTOOLS=true BUILD_JAXP=false BUILD_JAXWS=false BUILD_CORBA=false BUILD_HOTSPOT=true BUILD_JDK=true " # Execute the above sets, into the environment. for s in $sets; do eval export $s; done # Preview sets in command line for s do case $s in *'[ ;]'*) break;; *'='*) eval "$s";; *) break;; esac done # Incremental JVM rebuilds have trouble with *.gch files. # The *.gch file does not get regenerated unless you remove it, # even if 20 header files have changed. # This is not a problem for batch builds, of course. $BUILD_HOTSPOT && { ${KEEP_HOTSPOT_HEADERS:-false} || rm -f $(find build -name _precompiled.incl.gch) } # Run make, or whatever, in the resulting environment. eval "${@-make}" # Usage example: For a partial (re-)build of JDK only: # sh build.sh BUILD_{HOTSPOT,LANGTOOLS}=false make From Christian.Thalinger at Sun.COM Wed Nov 25 09:30:14 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Wed, 25 Nov 2009 18:30:14 +0100 Subject: mlvm don't build In-Reply-To: References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> <1259155416.894.9.camel@macbook> Message-ID: <1259170214.894.23.camel@macbook> On Wed, 2009-11-25 at 11:47 -0500, Stephen Bannasch wrote: > I'n new at using hg ... when I ran hg fpull -u in the root of my bsd-port dir many directories report as unchanged but these three reported that they were skipped: > > [hotspot] > skipped: 'hotspot' has mq patches applied > > [jdk] > skipped: 'jdk' has mq patches applied > > [langtools] > skipped: 'langtools' has mq patches applied > > It seems like the current state of my repo is blocking needed updates. Right. I normally pop all patches manually: $ cd hotspot $ hg qpop -a ... > > What are the mq patches? The mercurial queues (hotspot, jdk, langtools) contain all mlvm patches required. > What's the best way to bring my local hg repos back to a state where > hg fpull -u will pull in and apply the patches I need? See above. -- Christian From john.rose at sun.com Wed Nov 25 12:52:58 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Wed, 25 Nov 2009 20:52:58 +0000 Subject: hg: mlvm/mlvm: include instructions for refreshing patches and sources Message-ID: <20091125205258.5BB2741D45@hg.openjdk.java.net> Changeset: 1317d1aa6fdf Author: jrose Date: 2009-11-25 12:52 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/1317d1aa6fdf include instructions for refreshing patches and sources ! README.txt ! make/each-patch-repo.sh From John.Rose at Sun.COM Wed Nov 25 12:54:01 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 25 Nov 2009 12:54:01 -0800 Subject: mlvm don't build In-Reply-To: References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> <1259155416.894.9.camel@macbook> Message-ID: <0702CAE0-E012-40F0-B117-FF7CEE56B08B@sun.com> On Nov 25, 2009, at 9:03 AM, Stephen Bannasch wrote: > FYI: more information about my update process (which isn't working yet): It's a lot of commands! I've updated the file $davinci/patches/README.txt to describe how to refresh patches and sources. Please let me know if it helps, or if you find bugs in it. -- John From stephen.bannasch at deanbrook.org Wed Nov 25 14:31:42 2009 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 25 Nov 2009 17:31:42 -0500 Subject: mlvm don't build In-Reply-To: <1259170214.894.23.camel@macbook> References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> <1259155416.894.9.camel@macbook> <1259170214.894.23.camel@macbook> Message-ID: >On Wed, 2009-11-25 at 11:47 -0500, Stephen Bannasch wrote: > > It seems like the current state of my repo is blocking needed updates. > >Right. I normally pop all patches manually: > >$ cd hotspot >$ hg qpop -a >... > > > > > What are the mq patches? > >The mercurial queues (hotspot, jdk, langtools) contain all mlvm patches >required. > > > What's the best way to bring my local hg repos back to a state where > > hg fpull -u will pull in and apply the patches I need? > >See above. > >-- Christian Thanks for that tip Christian, I got much further in the process. Here's my updated script I am using to build: http://gist.github.com/243072 The build stopped in this section: <<>>Recursively making redist all @ Wed Nov 25 14:22:49 EST 2009 ... Here's the console output bracketing the error: /bin/mv /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib/classlist.temp /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib/classlist if [ "" = "" ] ; then /bin/mkdir -p /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib ; ( cd /NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/bsd-i586 && /bin/cp lib/orb.idl lib/ir.idl /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib ) ; fi /bin/sh: line 0: cd: /NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/bsd-i586: No such file or directory make[4]: *** [/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/tmp/java/components_imported] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 From John.Rose at Sun.COM Wed Nov 25 14:48:31 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 25 Nov 2009 14:48:31 -0800 Subject: mlvm don't build In-Reply-To: References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> <1259155416.894.9.camel@macbook> <1259170214.894.23.camel@macbook> Message-ID: On Nov 25, 2009, at 2:31 PM, Stephen Bannasch wrote: > Here's my updated script I am using to build: http://gist.github.com/243072 > > The build stopped in this section: > > Here's the console output bracketing the error: > > /bin/mv /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib/classlist.temp /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib/classlist > if [ "" = "" ] ; then /bin/mkdir -p /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib ; ( cd /NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/bsd-i586 && /bin/cp lib/orb.idl lib/ir.idl /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib ) ; fi > /bin/sh: line 0: cd: /NOT-SET/re/jdk/1.7.0/promoted/latest/binaries/bsd-i586: No such file or directory The diff between my build.sh and yours contains the following chunk for the environment variables. Maybe one of those settings is the problem. -- John sets=" - ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3/ + ALT_JIBX_LIBS_PATH=$HOME/Downloads/jibx/lib + ALT_JDK_IMPORT_PATH=/usr/local/soylatte16-i386-1.0.3 + ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 + ALT_BINARY_PLUGS_PATH=$HOME/Downloads/JDK7/jdk-7-icedtea-plugs ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib - ALT_JIBX_LIBS_PATH=/Users/stephen/dev/java/jibx/lib ANT_HOME=/usr/share/ant NO_DOCS=true - HOTSPOT_BUILD_JOBS=3 + HOTSPOT_BUILD_JOBS=2 BUILD_LANGTOOLS=true BUILD_JAXP=false BUILD_JAXWS=false BUILD_CORBA=false BUILD_HOTSPOT=true BUILD_JDK=true + CC=gcc-4.0 + CXX=g++-4.0 + ALT_COMPILER_PATH=$(pwd -P)/ALT_COMPILER_PATH/ + LD_LIBRARY_PATH= " -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091125/db737a29/attachment.html From stephen.bannasch at deanbrook.org Wed Nov 25 19:38:04 2009 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 25 Nov 2009 22:38:04 -0500 Subject: mlvm don't build In-Reply-To: References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> <1259155416.894.9.camel@macbook> <1259170214.894.23.camel@macbook> Message-ID: At 2:48 PM -0800 11/25/09, John Rose wrote: >+ CC=gcc-4.0 >+ CXX=g++-4.0 >+ ALT_COMPILER_PATH=$(pwd -P)/ALT_COMPILER_PATH/ I'm confused about what ALT_COMPILER_PATH is supposed to refer to. I'm getting errors like: /bin/sh: /Users/stephen/dev/java/src/bsd-port/ALT_COMPILER_PATH/gcc: No such file or directory From stephen.bannasch at deanbrook.org Wed Nov 25 19:55:23 2009 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 25 Nov 2009 22:55:23 -0500 Subject: mlvm don't build In-Reply-To: References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> <1259155416.894.9.camel@macbook> <1259170214.894.23.camel@macbook> Message-ID: >At 2:48 PM -0800 11/25/09, John Rose wrote: >>+ CC=gcc-4.0 >>+ CXX=g++-4.0 >>+ ALT_COMPILER_PATH=$(pwd -P)/ALT_COMPILER_PATH/ > >I'm confused about what ALT_COMPILER_PATH is supposed to refer to. > >I'm getting errors like: > >/bin/sh: /Users/stephen/dev/java/src/bsd-port/ALT_COMPILER_PATH/gcc: No such file or directory > I should have searched a bit harder before asking ;-) At 2:34 PM -0700 10/7/09, John Rose wrote: >-------- > export ALT_COMPILER_PATH=$(pwd -P)/ALT_COMPILER_PATH/ >-------- > ls -la ALT_COMPILER_PATH/ >total 24 >drwxr-xr-x 5 jrose staff 170 Oct 3 16:59 . >drwxr-xr-x 30 jrose staff 1020 Oct 7 14:30 .. >lrwxr-xr-x 1 jrose staff 8 Oct 3 16:58 .SOURCE ->/usr/bin >lrwxr-xr-x 1 jrose staff 15 Oct 3 16:59 g++ -> .SOURCE/g++-4.0 >lrwxr-xr-x 1 jrose staff 15 Oct 3 16:59 gcc -> .SOURCE/gcc-4.0 >-------- > >Maybe that's your problem too? (And maybe there's a better way than mine to fix it?) Basically, the forest-level makefile does not respect those environment variables, although the hotspot repo. makefiles do. It's confusing, butapparently the forest-level makefiles refer to the jdk repo. makefiles, which in turn have the names "gcc", "g++"hard-coded, and require a setting to ALT_COMPILER_PATH to override. > >I think the philosophy here (Kelly O'Hair would know for sure) is to minimize the environmental inputs to the makefiles, makingthem be clearly marked, hence the "ALT_" convention. > >-- John From stephen.bannasch at deanbrook.org Wed Nov 25 21:46:49 2009 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Thu, 26 Nov 2009 00:46:49 -0500 Subject: mlvm don't build ... now it does! In-Reply-To: References: <4AEC59CC.9010605@univ-mlv.fr> <4AEE9A0C.5090101@gmail.com> <4B0117E6.8010302@gmail.com> <4B01223E.2020803@univ-mlv.fr> <4B012368.4000303@gmail.com> <1258370032.3086.43.camel@macbook> <1259155416.894.9.camel@macbook> <1259170214.894.23.camel@macbook> Message-ID: This is the updated script I use to build mlvm on Mac OS X 10.5.8: http://gist.github.com/243072 It might work fine on 10.6.x also. Thanks for the help John and Christian. From pbenedict at apache.org Fri Nov 27 15:20:53 2009 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 27 Nov 2009 17:20:53 -0600 Subject: Replacing # with backticks for exotic identifiers Message-ID: 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 From headius at headius.com Mon Nov 30 08:22:23 2009 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 30 Nov 2009 10:22:23 -0600 Subject: Replacing # with backticks for exotic identifiers In-Reply-To: References: Message-ID: For me, the # syntax is reminiscent of Ruby documentation syntax, as in Object#to_s, so I kinda like it. But really any syntax that's not too intrusive is cool with me. Backquotes seems like a reasonable option too. On Fri, Nov 27, 2009 at 5: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 glaforge at gmail.com Mon Nov 30 08:28:45 2009 From: glaforge at gmail.com (Guillaume Laforge) Date: Mon, 30 Nov 2009 17:28:45 +0100 Subject: Replacing # with backticks for exotic identifiers In-Reply-To: References: Message-ID: <197b18fc0911300828w3eac2343j1f20caaa190e3837@mail.gmail.com> For exotic names, Groovy's been using single or double quotes, so quotes (even backticks) would look okay. More okay than #. I like the fact quotes or backticks "surround" naturally the exotic name. But well, that's perhaps just a question of taste. But I agree the # syntax may clash with the potentially upcoming closure syntax, if ever that FCM variant were to be chosen. On Mon, Nov 30, 2009 at 17:22, Charles Oliver Nutter wrote: > For me, the # syntax is reminiscent of Ruby documentation syntax, as > in Object#to_s, so I kinda like it. But really any syntax that's not > too intrusive is cool with me. Backquotes seems like a reasonable > option too. > > On Fri, Nov 27, 2009 at 5: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 >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Guillaume Laforge Groovy Project Manager Head of Groovy Development at SpringSource http://www.springsource.com/g2one