From john.r.rose at oracle.com Sat May 1 18:24:40 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 01:24:40 +0000 Subject: hg: mlvm/mlvm/langtools: meth-ing: final version Message-ID: <20100502012441.081C344813@hg.openjdk.java.net> Changeset: f8ba90f78b93 Author: jrose Date: 2010-05-01 18:22 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/f8ba90f78b93 meth-ing: final version ! meth-ing-6939134.patch From john.r.rose at oracle.com Sat May 1 18:24:43 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 01:24:43 +0000 Subject: hg: mlvm/mlvm/jdk: meth-ing: final version Message-ID: <20100502012444.1A87244814@hg.openjdk.java.net> Changeset: 60d86e9ce16c Author: jrose Date: 2010-05-01 18:23 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/60d86e9ce16c meth-ing: final version ! meth-ing-6939134.patch ! meth.patch ! meth.test.patch From john.r.rose at oracle.com Sat May 1 18:24:46 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 01:24:46 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-ing: final version Message-ID: <20100502012447.526F844815@hg.openjdk.java.net> Changeset: cf78247117c5 Author: jrose Date: 2010-05-01 18:22 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/cf78247117c5 meth-ing: final version ! meth-ing-6939134.patch From john.r.rose at oracle.com Sat May 1 19:35:02 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 02:35:02 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-bcp: final version Message-ID: <20100502023502.752C54483A@hg.openjdk.java.net> Changeset: f27b440b367c Author: jrose Date: 2010-05-01 19:30 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f27b440b367c meth-bcp: final version ! meth-bcp-6939196.patch From john.r.rose at oracle.com Sat May 1 19:35:12 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 02:35:12 +0000 Subject: hg: mlvm/mlvm/jdk: meth-bcp: final version Message-ID: <20100502023512.294624483C@hg.openjdk.java.net> Changeset: 9d1eb315160b Author: jrose Date: 2010-05-01 19:29 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9d1eb315160b meth-bcp: final version ! meth-bcp-6939196.patch From john.r.rose at oracle.com Sat May 1 20:08:10 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 03:08:10 +0000 Subject: hg: mlvm/mlvm/langtools: 2 new changesets Message-ID: <20100502030810.EAFF944853@hg.openjdk.java.net> Changeset: 423e18903e43 Author: jrose Date: 2010-05-01 20:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/423e18903e43 meth-ver-6949040.patch + meth-ver-6949040.patch ! series Changeset: c2c8c3c2e692 Author: jrose Date: 2010-05-01 20:08 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/c2c8c3c2e692 meth-ldc: fix typo in unit test ! meth-ldc-6939203.patch From john.r.rose at oracle.com Sun May 2 01:20:21 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 02 May 2010 08:20:21 +0000 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets Message-ID: <20100502082021.E14F0448CA@hg.openjdk.java.net> Changeset: a0864fae6cfc Author: jrose Date: 2010-05-02 01:20 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a0864fae6cfc meth-conv: checkpoint ! meth-conv-6939861.patch Changeset: 42040c3522c5 Author: jrose Date: 2010-05-02 01:20 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/42040c3522c5 cpindex: incorporate review comments ! cpindex-6939207.patch From Christian.Thalinger at Sun.COM Mon May 3 02:40:13 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 03 May 2010 09:40:13 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-ldc-6939203: Updated to apply cleanly. Message-ID: <20100503094014.90C0244B63@hg.openjdk.java.net> Changeset: 80bdafcdcf03 Author: twisti Date: 2010-05-03 11:38 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/80bdafcdcf03 meth-ldc-6939203: Updated to apply cleanly. ! meth-ldc-6939203.patch From Christian.Thalinger at Sun.COM Mon May 3 03:58:14 2010 From: Christian.Thalinger at Sun.COM (Christian.Thalinger at Sun.COM) Date: Mon, 03 May 2010 10:58:14 +0000 Subject: hg: mlvm/mlvm/hotspot: meth-ldc-6939203: Something was wrong in the last merge. Message-ID: <20100503105814.6153344B8A@hg.openjdk.java.net> Changeset: 2483eb7dcf67 Author: twisti Date: 2010-05-03 12:57 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2483eb7dcf67 meth-ldc-6939203: Something was wrong in the last merge. ! meth-ldc-6939203.patch From Dalibor.Topic at Sun.COM Fri May 7 06:46:01 2010 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Fri, 07 May 2010 15:46:01 +0200 Subject: jvm lang summit in July? Message-ID: <4BE41999.6090001@sun.com> Via puredanger's twitter stream comes http://www.regonline.com/Checkin.asp?EventId=859228 cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: J?rgen Kunz From john.r.rose at oracle.com Sat May 8 14:35:50 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 08 May 2010 21:35:50 +0000 Subject: hg: mlvm/mlvm: indy-demo: add InlineCache demo Message-ID: <20100508213550.C200F44C59@hg.openjdk.java.net> Changeset: fa252dd74a58 Author: jrose Date: 2010-05-08 14:35 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/fa252dd74a58 indy-demo: add InlineCache demo ! netbeans/indy-demo/nbproject/project.properties ! netbeans/indy-demo/src/Hello.java ! netbeans/indy-demo/src/Main.java ! netbeans/indy-demo/src/recipes/FastAndSlow.java + netbeans/indy-demo/src/recipes/InlineCache.java From blackdrag at gmx.org Mon May 10 07:17:06 2010 From: blackdrag at gmx.org (Jochen Theodorou) Date: Mon, 10 May 2010 16:17:06 +0200 Subject: jvm lang summit in July? In-Reply-To: <4BE41999.6090001@sun.com> References: <4BE41999.6090001@sun.com> Message-ID: <4BE81562.3060902@gmx.org> Dalibor Topic wrote: > Via puredanger's twitter stream comes > http://www.regonline.com/Checkin.asp?EventId=859228 No reaction to this yet. The registration page has a link for the 2010 summit, but it points still to the 2009 version. bye Jochen -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ From forax at univ-mlv.fr Mon May 10 07:45:25 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 10 May 2010 16:45:25 +0200 Subject: jvm lang summit in July? In-Reply-To: <4BE81562.3060902@gmx.org> References: <4BE41999.6090001@sun.com> <4BE81562.3060902@gmx.org> Message-ID: <4BE81C05.3020907@univ-mlv.fr> Le 10/05/2010 16:17, Jochen Theodorou a ?crit : > Dalibor Topic wrote: > >> Via puredanger's twitter stream comes >> http://www.regonline.com/Checkin.asp?EventId=859228 >> > No reaction to this yet. The registration page has a link for the 2010 > summit, but it points still to the 2009 version. > > bye Jochen > I am trying to convince my wife to shift our holidays by one week :) R?mi PS: I've just commit a simple runtime compiler to php.reboot: http://code.google.com/p/phpreboot/source/browse/#svn/trunk/phpreboot/src/com/googlecode/phpreboot/compiler -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100510/db28bb40/attachment.html From forax at univ-mlv.fr Mon May 10 12:11:43 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 10 May 2010 21:11:43 +0200 Subject: Bug in MethodHandles.convertArguments Message-ID: <4BE85A6F.4020307@univ-mlv.fr> For me it's a new bug. I have checked with jdk7 latest binaries I will check with the mlvm repository sources when I will be at my office with a fast connection. public class ConvertBug { public static Object foo(Object o1, Object o2) { return null; } public static void main(String[] args) { MethodHandle mh = MethodHandles.lookup().findStatic(ConvertBug.class, "foo", MethodType.methodType( Object.class, Object.class, Object.class)); mh = MethodHandles.convertArguments(mh, MethodType.methodType(Object.class, int.class, Object.class)); System.out.println("print mh "+mh); } } Exception in thread "main" java.lang.IllegalArgumentException: mismatched parameter count at sun.dyn.MemberName.newIllegalArgumentException(MemberName.java:409) at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:654) at sun.dyn.ToGeneric.(ToGeneric.java:102) at sun.dyn.ToGeneric.of(ToGeneric.java:257) at sun.dyn.ToGeneric.make(ToGeneric.java:249) at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:671) at java.dyn.MethodHandles.convertArguments(MethodHandles.java:811) at ConvertBug.main(ConvertBug.java:15) and I don't see any workaround :( R?mi From orodriguez at roos.com Mon May 10 16:24:15 2010 From: orodriguez at roos.com (Oscar Rodriguez) Date: Mon, 10 May 2010 16:24:15 -0700 Subject: jvm lang summit in July? In-Reply-To: <4BE81C05.3020907@univ-mlv.fr> References: <4BE41999.6090001@sun.com> <4BE81562.3060902@gmx.org> <4BE81C05.3020907@univ-mlv.fr> Message-ID: <4BE8959F.7020107@roos.com> An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100510/433d4e3c/attachment.html From john.r.rose at oracle.com Mon May 10 17:41:39 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 10 May 2010 17:41:39 -0700 Subject: jvm lang summit in July? In-Reply-To: <4BE81562.3060902@gmx.org> References: <4BE41999.6090001@sun.com> <4BE81562.3060902@gmx.org> Message-ID: <8D8F4084-0CF8-485A-9048-23D24817AB06@oracle.com> On May 10, 2010, at 7:17 AM, Jochen Theodorou wrote: > No reaction to this yet. The registration page has a link for the 2010 > summit, but it points still to the 2009 version. The date is real (July 26-28). We pulled the date earlier this year because we don't want to overlap with JavaOne (in September, this year). Sorry about the stale web page. The web server won't deliver my new content. :-( Working on it. (Yes, I've already heard the "network is the computer" jokes.) The registration site is open for speakers only at present. As in previous years, we're getting the speakers signed up first. Remember, there are only about 80 seats in the whole room, so a large percentage of attendees are speakers. I'm proud to announce that one speaker will be Doug Lea. I expect we can make some more progress on figuring out this multi-core revolution we're in. -- John From raffaello.giulietti at gmail.com Tue May 11 00:31:05 2010 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 11 May 2010 09:31:05 +0200 Subject: Bug in MethodHandles.convertArguments In-Reply-To: <4BE85A6F.4020307@univ-mlv.fr> References: <4BE85A6F.4020307@univ-mlv.fr> Message-ID: <4BE907B9.7040509@gmail.com> Yes, this seems a bug to me, too. What about converting to Integer.class instead of int.class and letting the boxing duties to the language compiler? Raffaello On 2010-05-10 21:11, R?mi Forax wrote: > For me it's a new bug. > I have checked with jdk7 latest binaries > I will check with the mlvm repository sources when I will be at my > office with a fast connection. > > public class ConvertBug { > public static Object foo(Object o1, Object o2) { > return null; > } > > public static void main(String[] args) { > MethodHandle mh = > MethodHandles.lookup().findStatic(ConvertBug.class, "foo", > MethodType.methodType( Object.class, Object.class, Object.class)); > mh = MethodHandles.convertArguments(mh, > MethodType.methodType(Object.class, int.class, Object.class)); > System.out.println("print mh "+mh); > } > } > > Exception in thread "main" java.lang.IllegalArgumentException: > mismatched parameter count > at sun.dyn.MemberName.newIllegalArgumentException(MemberName.java:409) > at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:654) > at sun.dyn.ToGeneric.(ToGeneric.java:102) > at sun.dyn.ToGeneric.of(ToGeneric.java:257) > at sun.dyn.ToGeneric.make(ToGeneric.java:249) > at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:671) > at java.dyn.MethodHandles.convertArguments(MethodHandles.java:811) > at ConvertBug.main(ConvertBug.java:15) > > > and I don't see any workaround :( > > R?mi > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From forax at univ-mlv.fr Tue May 11 03:27:46 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 11 May 2010 12:27:46 +0200 Subject: Bug in MethodHandles.convertArguments In-Reply-To: <4BE907B9.7040509@gmail.com> References: <4BE85A6F.4020307@univ-mlv.fr> <4BE907B9.7040509@gmail.com> Message-ID: <4BE93122.209@univ-mlv.fr> Le 11/05/2010 09:31, Raffaello Giulietti a ?crit : > Yes, this seems a bug to me, too. > > What about converting to Integer.class instead of int.class and letting > the boxing duties to the language compiler? > > Raffaello > This code is extracted from a bigger code that try to avoid boxing if not necessary. echo a + 3 is compiled: aload (a) iconst_3 invokedynamic plus(Object,int)Object and at runtime if 'a' contains an Integer, I install a fast path that checks if 'a' is an Integer and calls int+int. So the fast path doesn't need to box '3'. The slow path, box the int and call a method that will modify the fast path. I am currently not a able to call that method because converting an int to an object doesn't work. I see two workarounds: - have one slow path by signatures: (int,Object), (double, Object), (Object, int) (Object, double), etc. - don't rely on convert and use filterArguments. R?mi > > On 2010-05-10 21:11, R?mi Forax wrote: > >> For me it's a new bug. >> I have checked with jdk7 latest binaries >> I will check with the mlvm repository sources when I will be at my >> office with a fast connection. >> >> public class ConvertBug { >> public static Object foo(Object o1, Object o2) { >> return null; >> } >> >> public static void main(String[] args) { >> MethodHandle mh = >> MethodHandles.lookup().findStatic(ConvertBug.class, "foo", >> MethodType.methodType( Object.class, Object.class, Object.class)); >> mh = MethodHandles.convertArguments(mh, >> MethodType.methodType(Object.class, int.class, Object.class)); >> System.out.println("print mh "+mh); >> } >> } >> >> Exception in thread "main" java.lang.IllegalArgumentException: >> mismatched parameter count >> at sun.dyn.MemberName.newIllegalArgumentException(MemberName.java:409) >> at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:654) >> at sun.dyn.ToGeneric.(ToGeneric.java:102) >> at sun.dyn.ToGeneric.of(ToGeneric.java:257) >> at sun.dyn.ToGeneric.make(ToGeneric.java:249) >> at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:671) >> at java.dyn.MethodHandles.convertArguments(MethodHandles.java:811) >> at ConvertBug.main(ConvertBug.java:15) >> >> >> and I don't see any workaround :( >> >> R?mi >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From raffaello.giulietti at gmail.com Tue May 11 06:18:59 2010 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 11 May 2010 15:18:59 +0200 Subject: Bug in MethodHandles.convertArguments In-Reply-To: <4BE93122.209@univ-mlv.fr> References: <4BE85A6F.4020307@univ-mlv.fr> <4BE907B9.7040509@gmail.com> <4BE93122.209@univ-mlv.fr> Message-ID: <4BE95943.9080903@gmail.com> On 2010-05-11 12:27, R?mi Forax wrote: > Le 11/05/2010 09:31, Raffaello Giulietti a ?crit : >> Yes, this seems a bug to me, too. >> >> What about converting to Integer.class instead of int.class and letting >> the boxing duties to the language compiler? >> >> Raffaello >> Mmmm, I see. However, filterArguments might not combine well with tail calls. So, let's hope that convertArguments will work as expected asap. Did you find out if it's indeed a bug? > > This code is extracted from a bigger code that try to avoid boxing > if not necessary. > > echo a + 3 > is compiled: > aload (a) > iconst_3 > invokedynamic plus(Object,int)Object > > and at runtime if 'a' contains an Integer, I install a fast path > that checks if 'a' is an Integer and calls int+int. > So the fast path doesn't need to box '3'. > The slow path, box the int and call a method that will modify > the fast path. > > I am currently not a able to call that method because converting > an int to an object doesn't work. > > I see two workarounds: > - have one slow path by signatures: > (int,Object), (double, Object), (Object, int) (Object, double), etc. > - don't rely on convert and use filterArguments. > > > R?mi > >> >> On 2010-05-10 21:11, R?mi Forax wrote: >> >>> For me it's a new bug. >>> I have checked with jdk7 latest binaries >>> I will check with the mlvm repository sources when I will be at my >>> office with a fast connection. >>> >>> public class ConvertBug { >>> public static Object foo(Object o1, Object o2) { >>> return null; >>> } >>> >>> public static void main(String[] args) { >>> MethodHandle mh = >>> MethodHandles.lookup().findStatic(ConvertBug.class, "foo", >>> MethodType.methodType( Object.class, Object.class, Object.class)); >>> mh = MethodHandles.convertArguments(mh, >>> MethodType.methodType(Object.class, int.class, Object.class)); >>> System.out.println("print mh "+mh); >>> } >>> } >>> >>> Exception in thread "main" java.lang.IllegalArgumentException: >>> mismatched parameter count >>> at sun.dyn.MemberName.newIllegalArgumentException(MemberName.java:409) >>> at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:654) >>> at sun.dyn.ToGeneric.(ToGeneric.java:102) >>> at sun.dyn.ToGeneric.of(ToGeneric.java:257) >>> at sun.dyn.ToGeneric.make(ToGeneric.java:249) >>> at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:671) >>> at java.dyn.MethodHandles.convertArguments(MethodHandles.java:811) >>> at ConvertBug.main(ConvertBug.java:15) >>> >>> >>> and I don't see any workaround :( >>> >>> R?mi >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From tuolin at gmail.com Tue May 11 07:45:29 2010 From: tuolin at gmail.com (Tuolin Chen) Date: Tue, 11 May 2010 22:45:29 +0800 Subject: coro patch issue Message-ID: Hi all, I'm new to mlvm and I'm trying to get Lukas' coro.patch to work. I grabbed the source and patches according to openjdk and mlvm build instructions. Everything is done on my laptop running Ubuntu 10.04 64bit version. Only coro patch is applied. Though it didn't apply cleanly with latest code base, the issue is minor and I fixed it by some trivial editing on the patch. The patched sources compiled fine, but generated a error when yielding to coroutine: # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/unsafe.cpp:1229 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/tuolin/Projs/davinci/sources/hotspot/src/share/vm/prims/unsafe.cpp:1229), pid=9191, tid=140737353991952 # Error: assert(current != __null,"NULL current coroutine in prepareSwitch") While debugging, the data does not appear to be corrupted. I also checked the sources, but failed to see the appropriate modification. Any help is greatly appreciated! Tuolin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100511/87215783/attachment.html From john.r.rose at oracle.com Tue May 11 15:07:06 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 May 2010 15:07:06 -0700 Subject: coro patch issue In-Reply-To: References: Message-ID: <18A8C6C7-9635-41C4-815D-BD30B0716255@oracle.com> On May 11, 2010, at 7:45 AM, Tuolin Chen wrote: > I'm new to mlvm and I'm trying to get Lukas' coro.patch to work. > > I grabbed the source and patches according to openjdk and mlvm build instructions. Everything is done on my laptop running Ubuntu 10.04 64bit version. Only coro patch is applied. Though it didn't apply cleanly with latest code base, the issue is minor and I fixed it by some trivial editing on the patch. Unless you are attempting a forward-port, the patches should only be attempted with the micro-version mentioned in the series file (patches/hotspot/series). Currently that is 88f9b6ef43ff. Is that the base you are starting with? > The patched sources compiled fine, but generated a error when yielding to coroutine: > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/unsafe.cpp:1229 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (/home/tuolin/Projs/davinci/sources/hotspot/src/share/vm/prims/unsafe.cpp:1229), pid=9191, tid=140737353991952 > # Error: assert(current != __null,"NULL current coroutine in prepareSwitch") > > While debugging, the data does not appear to be corrupted. I also checked the sources, but failed to see the appropriate modification. > > Any help is greatly appreciated! If you are starting with the right base revision, this sounds like a question for Lukas. Best wishes, -- John From john.r.rose at oracle.com Tue May 11 16:02:17 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 May 2010 16:02:17 -0700 Subject: Bug in MethodHandles.convertArguments In-Reply-To: <4BE93122.209@univ-mlv.fr> References: <4BE85A6F.4020307@univ-mlv.fr> <4BE907B9.7040509@gmail.com> <4BE93122.209@univ-mlv.fr> Message-ID: On May 11, 2010, at 3:27 AM, R?mi Forax wrote: > I am currently not a able to call that method because converting > an int to an object doesn't work. This feels like version skew. I'm trying to reproduce it locally. If your code doesn't work then my unit tests shouldn't either; but they do work. Are you sure you are using the same version of the JVM and JDK support files? What does "hg qapplied" say in the hotspot vs. the jdk repository of the sources used for the build? What about "hg log -l9"? -- John From forax at univ-mlv.fr Tue May 11 16:49:25 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 12 May 2010 01:49:25 +0200 Subject: Bug in MethodHandles.convertArguments In-Reply-To: References: <4BE85A6F.4020307@univ-mlv.fr> <4BE907B9.7040509@gmail.com> <4BE93122.209@univ-mlv.fr> Message-ID: <4BE9ED05.5080200@univ-mlv.fr> Le 12/05/2010 01:02, John Rose a ?crit : > On May 11, 2010, at 3:27 AM, R?mi Forax wrote: > > >> I am currently not a able to call that method because converting >> an int to an object doesn't work. >> > > This feels like version skew. I'm trying to reproduce it locally. > > If your code doesn't work then my unit tests shouldn't either; but they do work. > > Are you sure you are using the same version of the JVM and JDK support files? > > What does "hg qapplied" say in the hotspot vs. the jdk repository of the sources used for the build? What about "hg log -l9"? > > -- John > I only use jdk7 binaries and I haven't found the time to test with the mlvm repository. The problem seems to come from ToGeneric.java at line 102, The convertArguments raises an exception before the unsupported exception is raised. R?mi From john.r.rose at oracle.com Tue May 11 17:20:21 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 May 2010 17:20:21 -0700 Subject: Bug in MethodHandles.convertArguments In-Reply-To: <4BE9ED05.5080200@univ-mlv.fr> References: <4BE85A6F.4020307@univ-mlv.fr> <4BE907B9.7040509@gmail.com> <4BE93122.209@univ-mlv.fr> <4BE9ED05.5080200@univ-mlv.fr> Message-ID: On May 11, 2010, at 4:49 PM, R?mi Forax wrote: > I only use jdk7 binaries and I haven't found the time to test > with the mlvm repository. OK. I'm about to promote some new code to JDK7 and I would like to know ASAP if it breaks or fixes your code. Can you send me a JAR file to run as a test? -- John From john.r.rose at oracle.com Tue May 11 17:32:13 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 11 May 2010 17:32:13 -0700 Subject: jvm lang summit in July? In-Reply-To: <8D8F4084-0CF8-485A-9048-23D24817AB06@oracle.com> References: <4BE41999.6090001@sun.com> <4BE81562.3060902@gmx.org> <8D8F4084-0CF8-485A-9048-23D24817AB06@oracle.com> Message-ID: On May 10, 2010, at 5:41 PM, John Rose wrote: > The web server won't deliver my new content. OK, here's a step forward: http://jvmlangsummit.com/ Of course, the agenda is mostly empty space, but that's why our CFP is out. Your move! :-) -- John From john.r.rose at oracle.com Tue May 11 17:49:41 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 12 May 2010 00:49:41 +0000 Subject: hg: mlvm/mlvm/hotspot: meth, indy: rebase to bsd-port Message-ID: <20100512004941.E8DB0443C7@hg.openjdk.java.net> Changeset: 1534f8ebcf9a Author: jrose Date: 2010-05-11 17:48 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1534f8ebcf9a meth, indy: rebase to bsd-port ! series From john.r.rose at oracle.com Tue May 11 17:49:49 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 12 May 2010 00:49:49 +0000 Subject: hg: mlvm/mlvm/jdk: meth, indy: rebase to bsd-port Message-ID: <20100512004949.58976443C9@hg.openjdk.java.net> Changeset: 25f53668dd02 Author: jrose Date: 2010-05-11 17:49 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/25f53668dd02 meth, indy: rebase to bsd-port ! series From john.r.rose at oracle.com Tue May 11 17:49:51 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 12 May 2010 00:49:51 +0000 Subject: hg: mlvm/mlvm/langtools: meth, indy: rebase to bsd-port Message-ID: <20100512004951.9074A443CB@hg.openjdk.java.net> Changeset: edbc97c550e4 Author: jrose Date: 2010-05-11 17:49 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/edbc97c550e4 meth, indy: rebase to bsd-port ! meth-ing-6939134.patch ! series From forax at univ-mlv.fr Tue May 11 18:09:06 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 12 May 2010 03:09:06 +0200 Subject: Bug in MethodHandles.convertArguments In-Reply-To: References: <4BE85A6F.4020307@univ-mlv.fr> <4BE907B9.7040509@gmail.com> <4BE93122.209@univ-mlv.fr> <4BE9ED05.5080200@univ-mlv.fr> Message-ID: <4BE9FFB2.1060408@univ-mlv.fr> Le 12/05/2010 02:20, John Rose a ?crit : > On May 11, 2010, at 4:49 PM, R?mi Forax wrote: > > >> I only use jdk7 binaries and I haven't found the time to test >> with the mlvm repository. >> > > OK. I'm about to promote some new code to JDK7 and I would like to know ASAP if it breaks or fixes your code. Can you send me a JAR file to run as a test? > I am not ready to send a jar :) But the following code is a good test: command line: java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -cp classes ConvertBug public class ConvertBug { public static Object foo(Object o1, Object o2) { return null; } public static void main(String[] args) { MethodHandle mh = MethodHandles.lookup().findStatic(ConvertBug.class, "foo", MethodType.methodType( Object.class, Object.class, Object.class)); mh = MethodHandles.convertArguments(mh, MethodType.methodType(Object.class, int.class, Object.class)); System.out.println("print mh "+mh); } } > -- John > R?mi PS: it's 3am here, it's time to find my bed. From john.r.rose at oracle.com Tue May 11 18:26:58 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 12 May 2010 01:26:58 +0000 Subject: hg: mlvm/mlvm/hotspot: patch porting problem caused by 6939930 Message-ID: <20100512012658.C525C443D8@hg.openjdk.java.net> Changeset: d030826b2845 Author: jrose Date: 2010-05-11 18:26 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d030826b2845 patch porting problem caused by 6939930 + post-6939930-adjust.patch ! series From tuolin at gmail.com Tue May 11 18:37:12 2010 From: tuolin at gmail.com (Tuolin Chen) Date: Wed, 12 May 2010 09:37:12 +0800 Subject: coro patch issue In-Reply-To: <18A8C6C7-9635-41C4-815D-BD30B0716255@oracle.com> References: <18A8C6C7-9635-41C4-815D-BD30B0716255@oracle.com> Message-ID: On Wed, May 12, 2010 at 6:07 AM, John Rose wrote: > On May 11, 2010, at 7:45 AM, Tuolin Chen wrote: > > > I'm new to mlvm and I'm trying to get Lukas' coro.patch to work. > > > > I grabbed the source and patches according to openjdk and mlvm build > instructions. Everything is done on my laptop running Ubuntu 10.04 64bit > version. Only coro patch is applied. Though it didn't apply cleanly with > latest code base, the issue is minor and I fixed it by some trivial editing > on the patch. > > Unless you are attempting a forward-port, the patches should only be > attempted with the micro-version mentioned in the series file > (patches/hotspot/series). Currently that is 88f9b6ef43ff. Is that the base > you are starting with? > 'hg log' under hotspot directory shows these at the very top: changeset: 1431:88f9b6ef43ff tag: tip user: Greg Lewis date: Fri Apr 23 19:11:02 2010 -0700 summary: . Make changes to BSD to keep it in sync with Linux and/or Solaris. changeset: 1430:0fcfcfd6162e parent: 1359:1e976d3fd820 parent: 1429:765578777b6e user: Greg Lewis date: Mon Apr 19 20:41:10 2010 -0700 summary: Merge from main OpenJDK repository So I suppose I had the right revision? Cheers, Tuolin > > The patched sources compiled fine, but generated a error when yielding to > coroutine: > > > > # To suppress the following error report, specify this argument > > # after -XX: or in .hotspotrc: SuppressErrorAt=/unsafe.cpp:1229 > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # Internal Error > (/home/tuolin/Projs/davinci/sources/hotspot/src/share/vm/prims/unsafe.cpp:1229), > pid=9191, tid=140737353991952 > > # Error: assert(current != __null,"NULL current coroutine in > prepareSwitch") > > > > While debugging, the data does not appear to be corrupted. I also checked > the sources, but failed to see the appropriate modification. > > > > Any help is greatly appreciated! > > If you are starting with the right base revision, this sounds like a > question for Lukas. > > Best wishes, > -- John > _______________________________________________ > 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/20100512/32fb1266/attachment-0001.html From lukas.stadler at jku.at Wed May 12 09:07:08 2010 From: lukas.stadler at jku.at (Lukas Stadler) Date: Wed, 12 May 2010 18:07:08 +0200 Subject: coro patch issue In-Reply-To: References: Message-ID: <4BEAD22C.506@jku.at> Hi! Ok, I see... 64-bit support is something that I'm working on right now, I probably should've put in an assertion to make that clear. Sorry! It'll be finished in a week or so. (why are there different java calling conventions in linux and windows? argh...) I hope you're ok with using the 32-bit version until then. - Lukas On 11.05.2010 16:45, Tuolin Chen wrote: > Hi all, > > I'm new to mlvm and I'm trying to get Lukas' coro.patch to work. > > I grabbed the source and patches according to openjdk and mlvm build > instructions. Everything is done on my laptop running Ubuntu 10.04 > 64bit version. Only coro patch is applied. Though it didn't apply > cleanly with latest code base, the issue is minor and I fixed it by > some trivial editing on the patch. > > The patched sources compiled fine, but generated a error when yielding > to coroutine: > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/unsafe.cpp:1229 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/home/tuolin/Projs/davinci/sources/hotspot/src/share/vm/prims/unsafe.cpp:1229), > pid=9191, tid=140737353991952 > # Error: assert(current != __null,"NULL current coroutine in > prepareSwitch") > > While debugging, the data does not appear to be corrupted. I also > checked the sources, but failed to see the appropriate modification. > > Any help is greatly appreciated! > > Tuolin > > > _______________________________________________ > 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/20100512/3cc6f5ec/attachment.html From tuolin at gmail.com Wed May 12 20:53:40 2010 From: tuolin at gmail.com (Tuolin Chen) Date: Thu, 13 May 2010 11:53:40 +0800 Subject: coro patch issue In-Reply-To: <4BEAD22C.506@jku.at> References: <4BEAD22C.506@jku.at> Message-ID: Hi Lukas, Thanks for the info. I've also noticed that after looking deeper into the source code. the 32 bit build works great! Looking forward to your 64 bit patch. Best, --Tuolin On Thu, May 13, 2010 at 12:07 AM, Lukas Stadler wrote: > Hi! > > Ok, I see... 64-bit support is something that I'm working on right now, I > probably should've put in an assertion to make that clear. Sorry! > It'll be finished in a week or so. (why are there different java calling > conventions in linux and windows? argh...) > > I hope you're ok with using the 32-bit version until then. > > - Lukas > > > On 11.05.2010 16:45, Tuolin Chen wrote: > > Hi all, > > I'm new to mlvm and I'm trying to get Lukas' coro.patch to work. > > I grabbed the source and patches according to openjdk and mlvm build > instructions. Everything is done on my laptop running Ubuntu 10.04 64bit > version. Only coro patch is applied. Though it didn't apply cleanly with > latest code base, the issue is minor and I fixed it by some trivial editing > on the patch. > > The patched sources compiled fine, but generated a error when yielding to > coroutine: > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/unsafe.cpp:1229 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/home/tuolin/Projs/davinci/sources/hotspot/src/share/vm/prims/unsafe.cpp:1229), > pid=9191, tid=140737353991952 > # Error: assert(current != __null,"NULL current coroutine in > prepareSwitch") > > While debugging, the data does not appear to be corrupted. I also checked > the sources, but failed to see the appropriate modification. > > Any help is greatly appreciated! > > Tuolin > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.nethttp://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100513/7fff9095/attachment.html From forax at univ-mlv.fr Fri May 14 03:01:11 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 14 May 2010 12:01:11 +0200 Subject: MethodType and void as parameter type Message-ID: <4BED1F67.9020509@univ-mlv.fr> Hi all, trying to reproduce a bug in insertArguments, I have found another one in MethodType. The spec doesn't allow to use void.class as parameter type in MethodType but the RI throws a NPE. import java.dyn.MethodType; public class MethodTypeBug { public static void main(String[] args) { MethodType.methodType(void.class, void.class); } } Exception in thread "main" java.lang.NullPointerException at java.dyn.MethodType.toString(MethodType.java:540) at java.lang.String.valueOf(String.java:2893) at java.lang.StringBuilder.append(StringBuilder.java:128) at java.dyn.MethodType.checkPtypes(MethodType.java:100) at java.dyn.MethodType.(MethodType.java:88) at java.dyn.MethodType.makeImpl(MethodType.java:200) at java.dyn.MethodType.methodType(MethodType.java:168) at MethodTypeBug.main(MethodTypeBug.java:5) R?mi From forax at univ-mlv.fr Fri May 14 03:07:03 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 14 May 2010 12:07:03 +0200 Subject: Bug in MethodHandles.insertArguments Message-ID: <4BED20C7.2000409@univ-mlv.fr> Hi all, a rogue path in my implementation allows to bound null to a virtual method. Instead of a NPE, I got an InternalError :( import java.dyn.MethodHandle; import java.dyn.MethodHandles; import java.dyn.MethodType; public class InsertArgumentsBug { public int f(int i) { return i; } public static void main(String[] args) { MethodHandle mh = MethodHandles.lookup().findVirtual(InsertArgumentsBug.class, "f", MethodType.methodType(int.class, int.class)); mh = MethodHandles.insertArguments(mh, 0, (Object)null); } } Exception in thread "main" java.lang.InternalError at sun.dyn.MethodHandleNatives.init(Native Method) at sun.dyn.BoundMethodHandle.initTarget(BoundMethodHandle.java:96) at sun.dyn.BoundMethodHandle.(BoundMethodHandle.java:90) at sun.dyn.BoundMethodHandle.(BoundMethodHandle.java:75) at sun.dyn.MethodHandleImpl.bindReceiver(MethodHandleImpl.java:441) at java.dyn.MethodHandles.insertArguments(MethodHandles.java:994) at InsertArgumentsBug.main(InsertArgumentsBug.java:13) cheers, R?mi From john.r.rose at oracle.com Tue May 18 00:35:23 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 18 May 2010 07:35:23 +0000 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures Message-ID: <20100518073523.9979544F7B@hg.openjdk.java.net> Changeset: e2709716a4ea Author: jrose Date: 2010-05-18 00:35 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e2709716a4ea meth: add proxy maker for closures + meth-proxy-6953246.patch ! series From headius at headius.com Tue May 18 00:45:21 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 18 May 2010 07:45:21 +0000 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: <20100518073523.9979544F7B@hg.openjdk.java.net> References: <20100518073523.9979544F7B@hg.openjdk.java.net> Message-ID: Well this one looks interesting. I'm generating several thousand such abstract adapters; this would allow me to potentially use my same abstract supertype for them all with either indy or non-indy backing them up... On Tue, May 18, 2010 at 7:35 AM, wrote: > Changeset: e2709716a4ea > Author: ? ?jrose > Date: ? ? ?2010-05-18 00:35 -0700 > URL: ? ? ? http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e2709716a4ea > > meth: add proxy maker for closures > > + meth-proxy-6953246.patch > ! series > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From forax at univ-mlv.fr Tue May 18 00:59:32 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 18 May 2010 09:59:32 +0200 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: References: <20100518073523.9979544F7B@hg.openjdk.java.net> Message-ID: <4BF248E4.9070805@univ-mlv.fr> Le 18/05/2010 09:45, Charles Oliver Nutter a ?crit : > Well this one looks interesting. I'm generating several thousand such > abstract adapters; this would allow me to potentially use my same > abstract supertype for them all with either indy or non-indy backing > them up... > It's only useful when bridging JRuby and Java, by example when you want to call a method that take a java.util.Comparator from JRuby, otherwise plain old method handle avoid to create such proxy. You generate adapters as a workaroud of the signature polymorphism problem. java.dyn.MethodHandle is the solution. R?mi > On Tue, May 18, 2010 at 7:35 AM, wrote: > >> Changeset: e2709716a4ea >> Author: jrose >> Date: 2010-05-18 00:35 -0700 >> URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e2709716a4ea >> >> meth: add proxy maker for closures >> >> + meth-proxy-6953246.patch >> ! series >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From thobes at gmail.com Tue May 18 01:00:08 2010 From: thobes at gmail.com (Tobias Ivarsson) Date: Tue, 18 May 2010 10:00:08 +0200 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: References: <20100518073523.9979544F7B@hg.openjdk.java.net> Message-ID: It does indeed. Am I reading this correctly that we will now(/soon) be able to create proxies for abstract classes? On Tue, May 18, 2010 at 9:45 AM, Charles Oliver Nutter wrote: > Well this one looks interesting. I'm generating several thousand such > abstract adapters; this would allow me to potentially use my same > abstract supertype for them all with either indy or non-indy backing > them up... > > On Tue, May 18, 2010 at 7:35 AM, wrote: > > Changeset: e2709716a4ea > > Author: jrose > > Date: 2010-05-18 00:35 -0700 > > URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/e2709716a4ea > > > > meth: add proxy maker for closures > > > > + meth-proxy-6953246.patch > > ! series > > > > _______________________________________________ > > mlvm-dev mailing list > > mlvm-dev at openjdk.java.net > > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100518/22999ab1/attachment.html From john.r.rose at oracle.com Tue May 18 09:23:56 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 18 May 2010 09:23:56 -0700 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: References: <20100518073523.9979544F7B@hg.openjdk.java.net> Message-ID: <00D2E5D6-8051-4021-A81E-2D1DE3C7CEA9@oracle.com> On May 18, 2010, at 1:00 AM, Tobias Ivarsson wrote: > It does indeed. Am I reading this correctly that we will now(/soon) be able to create proxies for abstract classes? Maybe; it's just a draft so far. I expect *not* to use reflect.Proxy; we need something more opaque and optimizable. There is some discussion for closures around "What's a SAM type?" and I want to be ready for an expansive answer. -- John From john.r.rose at oracle.com Tue May 18 10:18:26 2010 From: john.r.rose at oracle.com (John Rose) Date: Tue, 18 May 2010 10:18:26 -0700 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: <4BF248E4.9070805@univ-mlv.fr> References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> Message-ID: On May 18, 2010, at 12:59 AM, R?mi Forax wrote: > It's only useful when bridging JRuby and Java, It could also be useful for bridging language A to language B. For example, Clojure has a suite of Function interfaces. But the key use is as you say, for interoperating with the Java platform APIs. -- John From Christian.Thalinger at Sun.COM Tue May 18 11:26:17 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 18 May 2010 20:26:17 +0200 Subject: Fail to build JDK on OSX Snow Leopard In-Reply-To: References: Message-ID: <1274207177.1373.31.camel@macbook> [mlvm-dev would be more appropriate. I'm CC'ing.] On Tue, 2010-05-18 at 19:37 +0200, Eric Bodden wrote: > Hello. > > I hope this is the right mailing list for this. If not, please correct > me. I am trying to build JDK 7 on OSX Snow Leopard, to try out the new > invokedynamic support. Yeah, we know there is a problem on Mac OS X. John Rose is already working on a fix for that. -- Christian From headius at headius.com Tue May 18 13:18:32 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 18 May 2010 20:18:32 +0000 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> Message-ID: On Tue, May 18, 2010 at 5:18 PM, John Rose wrote: > On May 18, 2010, at 12:59 AM, R?mi Forax wrote: > >> It's only useful when bridging JRuby and Java, > > It could also be useful for bridging language A to language B. > > For example, Clojure has a suite of Function interfaces. > > But the key use is as you say, for interoperating with the Java platform APIs. One important question for me is how multi-method interfaces would be handled. I had originally tried to use Scala's "Function" interfaces in Duby to represent closures, but they all have multiple abstract methods that must be handled completely differently. I'd need to provide my own superclass with default behavior or have a way to stitch together N handles for N abstract methods. And I agree about the language bridging...plus in the JRuby case, this actually makes Ruby to Ruby bridging easier: * We need a codebase that works on Java 6 * ...so we can't move our entire call path to using MethodHandle * ...so we need our own abstract "invoker" supertype * ...so being able to use that supertype with either generated impls or MethodHandle-provided impls makes it easier for us to support both indy and non-indy runtimes in the same implementation. Perhaps this also helps Java 7 closures work nicer by making it possible to have a generic Closure or Function superclass completely independent of java.dyn? Or by making it possible to implement (faster) Java reflection with fewer generic frames under the covers via a single abstract supertype populated by indy? Seems like a good addition, in any case, but especially once it's faster and more direct than reflect.Proxy :) - Charlie From forax at univ-mlv.fr Tue May 18 14:44:11 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 18 May 2010 23:44:11 +0200 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> Message-ID: <4BF30A2B.4080800@univ-mlv.fr> [...] > One important question for me is how multi-method interfaces would be > handled. I had originally tried to use Scala's "Function" interfaces > in Duby to represent closures, but they all have multiple abstract > methods that must be handled completely differently. I'd need to > provide my own superclass with default behavior or have a way to > stitch together N handles for N abstract methods. > You can construct a tree of method handles, like Attila's code does. > And I agree about the language bridging...plus in the JRuby case, this > actually makes Ruby to Ruby bridging easier: > > * We need a codebase that works on Java 6 > * ...so we can't move our entire call path to using MethodHandle > * ...so we need our own abstract "invoker" supertype > * ...so being able to use that supertype with either generated impls > or MethodHandle-provided impls makes it easier for us to support both > indy and non-indy runtimes in the same implementation. > I think that you should maintain two codebases (I am not kidding), because to really unleash the power of JSR 292 you have to use MethodHandle every where. If all your codebase use method handles, you don't need boxing anymore along the whole path, you can jump back and forth between the interpreter and the runtime compiled code, you can share dynamic stubs (by example the one you use to resolve the operator +) between the interpreter and the runtime compiler, and even try to share profiles between them (I say try here because I have only a hackish solution) etc. And you can do all of that with the few lines of codes because the API allow you to work at a meta-level. > Perhaps this also helps Java 7 closures work nicer by making it > possible to have a generic Closure or Function superclass completely > independent of java.dyn? Or by making it possible to implement > (faster) Java reflection with fewer generic frames under the covers > via a single abstract supertype populated by indy? > And your generic Closure/Function will be not a lot of different from a method handle. > Seems like a good addition, in any case, but especially once it's > faster and more direct than reflect.Proxy :) > > - Charlie > R?mi From forax at univ-mlv.fr Fri May 21 01:16:50 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 21 May 2010 10:16:50 +0200 Subject: Crash in JIT compiler with server VM Message-ID: <4BF64172.4080500@univ-mlv.fr> Hi John & Christian, the JIT compiler of C2 seems to have a problem with this code (see VMCrash.java). I use jdk7b92. Step to reproduce: compile VMChrash and RT.java run with: java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic VMCrash R?mi -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RT.java Url: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100521/14f433f7/attachment-0003.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: VMCrash.java Url: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100521/14f433f7/attachment-0004.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hs_err_pid14792.log Url: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20100521/14f433f7/attachment-0005.ksh From Christian.Thalinger at Sun.COM Fri May 21 02:25:26 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 21 May 2010 11:25:26 +0200 Subject: Crash in JIT compiler with server VM In-Reply-To: <4BF64172.4080500@univ-mlv.fr> References: <4BF64172.4080500@univ-mlv.fr> Message-ID: <1274433926.21073.2.camel@macbook> On Fri, 2010-05-21 at 10:16 +0200, R?mi Forax wrote: > Hi John & Christian, > the JIT compiler of C2 seems to have a problem with this code (see > VMCrash.java). > I use jdk7b92. > > Step to reproduce: > compile VMChrash and RT.java > run with: java -server -XX:+UnlockExperimentalVMOptions > -XX:+EnableInvokeDynamic VMCrash This is all getting very complicated. Indeed it crashes with older builds. I just wanted to try a recent hotspot-comp build but the test does not work because of the recent CallSite constructor changes. -- Christian From Christian.Thalinger at Sun.COM Fri May 21 02:42:32 2010 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Fri, 21 May 2010 11:42:32 +0200 Subject: Crash in JIT compiler with server VM In-Reply-To: <1274433926.21073.2.camel@macbook> References: <4BF64172.4080500@univ-mlv.fr> <1274433926.21073.2.camel@macbook> Message-ID: <1274434952.21073.4.camel@macbook> On Fri, 2010-05-21 at 11:25 +0200, Christian Thalinger wrote: > On Fri, 2010-05-21 at 10:16 +0200, R?mi Forax wrote: > > Hi John & Christian, > > the JIT compiler of C2 seems to have a problem with this code (see > > VMCrash.java). > > I use jdk7b92. > > > > Step to reproduce: > > compile VMChrash and RT.java > > run with: java -server -XX:+UnlockExperimentalVMOptions > > -XX:+EnableInvokeDynamic VMCrash > > This is all getting very complicated. Indeed it crashes with older > builds. I just wanted to try a recent hotspot-comp build but the test > does not work because of the recent CallSite constructor changes. I built a HotSpot based on 2338d41fbd81 (the changeset before John's changes) and ran with the brand new JDK7 b94: $ gamma -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic VMCrash VM option '+UnlockExperimentalVMOptions' VM option '+EnableInvokeDynamic' Exception in thread "main" java.dyn.InvokeDynamicBootstrapError: exception thrown while linking at sun.dyn.CallSiteImpl.makeSite(CallSiteImpl.java:85) at VMCrash.f(VMCrash.java:8) at VMCrash.main(VMCrash.java:16) Caused by: java.lang.IllegalArgumentException: bad adapter (conversion=0x00000100): type mismatch: returning a int, but caller expects boolean at sun.dyn.MethodHandleNatives.init(Native Method) at sun.dyn.AdapterMethodHandle.(AdapterMethodHandle.java:53) at sun.dyn.AdapterMethodHandle.(AdapterMethodHandle.java:58) at sun.dyn.AdapterMethodHandle.makeRetype(AdapterMethodHandle.java:478) at sun.dyn.AdapterMethodHandle.makeRetypeRaw(AdapterMethodHandle.java:468) at sun.dyn.ToGeneric.(ToGeneric.java:148) at sun.dyn.ToGeneric.of(ToGeneric.java:257) at sun.dyn.ToGeneric.make(ToGeneric.java:249) at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:671) at java.dyn.MethodHandles.convertArguments(MethodHandles.java:811) at RT.bootstrap(RT.java:451) at sun.dyn.CallSiteImpl.makeSite(CallSiteImpl.java:83) ... 2 more -- Christian From forax at univ-mlv.fr Sat May 22 16:55:51 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 23 May 2010 01:55:51 +0200 Subject: VM and JDK classes aren't aligned Message-ID: <4BF86F07.2060406@univ-mlv.fr> Hi all, testing my pet project with jdk7b94, I get a crash (with c1 or c2). The crash apperas before the main is executed Commandline: java -server -XX:+AnonymousClasses -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -Xbootclasspath/a:$LIB/phpreboot.jar:$LIB/tatoo-runtime.jar:$LIB/asm-all-3.2.jar com.googlecode.phpreboot.Main $@ Invalid layout of java.dyn.CallSite at target # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (javaClasses.cpp:48), pid=2110, tid=1604464 # fatal error: Invalid layout of preloaded class # # JRE version: 7.0-b94 # Java VM: Java HotSpot(TM) Client VM (19.0-b01 mixed mode, sharing linux-x86 ) # An error report file with more information is saved as: # /home/forax/java/workspace/phpreboot/hs_err_pid2110.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Abandon (core dumped) I know that jdk7b92 doesn't exhibit this error. R?mi From john.r.rose at oracle.com Sat May 22 19:29:51 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 22 May 2010 19:29:51 -0700 Subject: VM and JDK classes aren't aligned In-Reply-To: <4BF86F07.2060406@univ-mlv.fr> References: <4BF86F07.2060406@univ-mlv.fr> Message-ID: I recently committed to JDK7 a bundle of coordinated changes to the JDK and JVM. It looks like we failed to promote, in jdk7-b92, the JDK changes that go with the most recent JVM changes. These JVM changes are in hs19-b01. The JDK changes will catch up in jdk7-b93. (Reminder: This mismatch only affects people who use UnlockExperimentalVMOptions and EnableInvokeDynamic or EnableMethodHandles.) For now, please grab this file and prepend it onto your BCP: http://blogs.sun.com/jrose/resource/jsr292/hs19-b01-jsr292-patch.jar Here's the option, of course: -Xbootclasspath/p:$DOWNLOADS/hs19-b01-jsr292-patch.jar Current unit tests are in this file: http://blogs.sun.com/jrose/resource/jsr292/hs19-b01-jsr292-tests.jar It requires a recent version of JUnit (4.5 or better): http://www.junit.org/node/401 Here's the complete command line: $JAVA7_HOME/bin/java} \ -XX:+{UnlockExperimentalVMOptions,EnableInvokeDynamic} \ -Xbootclasspath/p:$DOWNLOADS/hs19-b01-jsr292-patch.jar \ -cp $$DOWNLOADS/hs19-b01-jsr292-tests.jar:$DOWNLOADS/junit-4.5.jar \ org.junit.runner.JUnitCore test.java.dyn.MethodHandlesTest Sorry for the trouble. Please let me know if this works. -- John On May 22, 2010, at 4:55 PM, R?mi Forax wrote: > Hi all, > testing my pet project with jdk7b94, I get a crash (with c1 or c2). > The crash apperas before the main is executed > > Commandline: > java -server -XX:+AnonymousClasses -XX:+UnlockExperimentalVMOptions > -XX:+EnableInvokeDynamic > -Xbootclasspath/a:$LIB/phpreboot.jar:$LIB/tatoo-runtime.jar:$LIB/asm-all-3.2.jar > com.googlecode.phpreboot.Main $@ > > Invalid layout of java.dyn.CallSite at target > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (javaClasses.cpp:48), pid=2110, tid=1604464 > # fatal error: Invalid layout of preloaded class > # > # JRE version: 7.0-b94 > # Java VM: Java HotSpot(TM) Client VM (19.0-b01 mixed mode, sharing > linux-x86 ) > # An error report file with more information is saved as: > # /home/forax/java/workspace/phpreboot/hs_err_pid2110.log > # > # If you would like to submit a bug report, please visit: > # http://java.sun.com/webapps/bugreport/crash.jsp > # > Abandon (core dumped) > > I know that jdk7b92 doesn't exhibit this error. > > R?mi > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From john.r.rose at oracle.com Sat May 22 23:55:33 2010 From: john.r.rose at oracle.com (John Rose) Date: Sat, 22 May 2010 23:55:33 -0700 Subject: VM and JDK classes aren't aligned In-Reply-To: References: <4BF86F07.2060406@univ-mlv.fr> Message-ID: <00D7AFB3-7120-43A0-9C45-E761B409F955@oracle.com> On May 22, 2010, at 7:29 PM, John Rose wrote: > I recently committed to JDK7 a bundle of coordinated changes to the JDK and JVM. It looks like we failed to promote, in jdk7-b92, the JDK changes that go with the most recent JVM changes. These JVM changes are in hs19-b01. > > The JDK changes will catch up in jdk7-b93. Correction: The build numbers are b94 (broken) and b95 (will be fixed), respectively. -- John From john.r.rose at oracle.com Sun May 23 01:47:29 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 23 May 2010 08:47:29 +0000 Subject: hg: mlvm/mlvm/hotspot: cpindex: fix minor bugs; reorder series file to reflect recent and pending pushes Message-ID: <20100523084729.9E29144516@hg.openjdk.java.net> Changeset: c86d76b9ca2b Author: jrose Date: 2010-05-23 01:46 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c86d76b9ca2b cpindex: fix minor bugs; reorder series file to reflect recent and pending pushes ! cpindex-6939207.patch ! series From john.r.rose at oracle.com Sun May 23 02:45:40 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sun, 23 May 2010 09:45:40 +0000 Subject: hg: mlvm/mlvm/jdk: cpindex: reorder series file to reflect recent and pending pushes; tweak MethodHandlesTest Message-ID: <20100523094540.E391644519@hg.openjdk.java.net> Changeset: faa3aa1522e2 Author: jrose Date: 2010-05-23 02:45 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/faa3aa1522e2 cpindex: reorder series file to reflect recent and pending pushes; tweak MethodHandlesTest ! meth-ldc-6939203.patch ! series From forax at univ-mlv.fr Sun May 23 03:44:26 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 23 May 2010 12:44:26 +0200 Subject: VM and JDK classes aren't aligned In-Reply-To: References: <4BF86F07.2060406@univ-mlv.fr> Message-ID: <4BF9070A.3060006@univ-mlv.fr> Le 23/05/2010 04:29, John Rose a ?crit : > I recently committed to JDK7 a bundle of coordinated changes to the JDK and JVM. It looks like we failed to promote, in jdk7-b92, the JDK changes that go with the most recent JVM changes. These JVM changes are in hs19-b01. > > The JDK changes will catch up in jdk7-b93. > > (Reminder: This mismatch only affects people who use UnlockExperimentalVMOptions and EnableInvokeDynamic or EnableMethodHandles.) > In fact only UnlockExperimentalVMOptions and EnableInvokeDynamic fails, method handles seems to work :) > For now, please grab this file and prepend it onto your BCP: > http://blogs.sun.com/jrose/resource/jsr292/hs19-b01-jsr292-patch.jar > > Here's the option, of course: > -Xbootclasspath/p:$DOWNLOADS/hs19-b01-jsr292-patch.jar > > Current unit tests are in this file: > http://blogs.sun.com/jrose/resource/jsr292/hs19-b01-jsr292-tests.jar > > It requires a recent version of JUnit (4.5 or better): > http://www.junit.org/node/401 > > Here's the complete command line: > $JAVA7_HOME/bin/java} \ > -XX:+{UnlockExperimentalVMOptions,EnableInvokeDynamic} \ > -Xbootclasspath/p:$DOWNLOADS/hs19-b01-jsr292-patch.jar \ > -cp $$DOWNLOADS/hs19-b01-jsr292-tests.jar:$DOWNLOADS/junit-4.5.jar \ > org.junit.runner.JUnitCore test.java.dyn.MethodHandlesTest > > Sorry for the trouble. Please let me know if this works. > It works :) > -- John > R?mi From fredrik.ohrstrom at oracle.com Sun May 23 10:21:47 2010 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?IkZyZWRyaWsgw5ZocnN0csO2bSI=?=) Date: Sun, 23 May 2010 10:21:47 -0700 (PDT) Subject: Sv: hg: mlvm/mlvm/jdk: cpindex: reorder series file to reflect recent and pending pushes; tweak MethodHandlesTest Message-ID: <68a0e60c-38b5-4c6c-827f-08e5105650dc@default> What are the patches needed to build with full MethodHandle support. The wiki page http://wikis.sun.com/display/mlvm/Building says that the patche guards "buildable testable" should be used. This is clearly not enough. It seems like 6939203 and at least something more is needed. What are the exact patches needed for full MethodHandle support? //Fredrik ----- Ursprungligt meddelande ----- Fr?n: john.r.rose at oracle.com Till: mlvm-dev at openjdk.java.net, mr at sun.com Skickat: s?ndag, 23 maj 2010 11:46:21 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien ?mne: hg: mlvm/mlvm/jdk: cpindex: reorder series file to reflect recent and pending pushes; tweak MethodHandlesTest Changeset: faa3aa1522e2 Author: jrose Date: 2010-05-23 02:45 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/faa3aa1522e2 cpindex: reorder series file to reflect recent and pending pushes; tweak MethodHandlesTest ! meth-ldc-6939203.patch ! series _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From forax at univ-mlv.fr Sun May 23 10:29:52 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 23 May 2010 19:29:52 +0200 Subject: Bug in invokeGeneric Message-ID: <4BF96610.90507@univ-mlv.fr> Here is a test that doesn't pass with jdk7b94 (it's a regression). It raises a WrongMethodTypeException. The workaround is to convert the method handle to use a generic signature (uncomment the line before the last line). Exception in thread "main" java.dyn.WrongMethodTypeException: (II)Z cannot be called as (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; at MHInvokeGenericBug.main(MHInvokeGenericBug.java:19) import java.dyn.MethodHandle; import java.dyn.MethodHandles; import java.dyn.MethodType; public class MHInvokeGenericBug { public boolean foo(int i, int i2) { return i == i2; } public static void main(String[] args) throws Throwable { MethodHandle mh = MethodHandles.lookup().findVirtual(MHInvokeGenericBug.class, "foo", MethodType.methodType(boolean.class, int.class, int.class)); MHInvokeGenericBug bug = new MHInvokeGenericBug(); //mh = mh.asType(MethodType.methodType(Object.class, Object.class, Object.class, Object.class)); System.out.println(mh.invokeGeneric(bug, 27, 42)); } } R?mi From forax at univ-mlv.fr Sun May 23 15:01:03 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 24 May 2010 00:01:03 +0200 Subject: InvokeVarargs with a method with more than 10 arguments Message-ID: <4BF9A59F.7090706@univ-mlv.fr> I got a NYI if I try to call a method using invokeVarargs with more than 10 arguments. R?mi trace:invokeVarargs (java.lang.Object,double,com.googlecode.phpreboot.model.Function,com.googlecode.phpreboot.model.Function,com.googlecode.phpreboot.model.Function,com.googlecode.phpreboot.model.Function,double,com.googlecode.phpreboot.model.Var,com.googlecode.phpreboot.model.Var,com.googlecode.phpreboot.model.Var,com.googlecode.phpreboot.model.Var,com.googlecode.phpreboot.model.Var,com.googlecode.phpreboot.model.Var)void com.googlecode.phpreboot.runtime.RT$RTError: NYI at com.googlecode.phpreboot.runtime.RT.error(RT.java:47) at com.googlecode.phpreboot.compiler.Compiler.traceCompile(Compiler.java:179) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:467) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:1) at com.googlecode.phpreboot.ast.LabeledInstrWhile.accept(LabeledInstrWhile.java:38) at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:188) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:361) at com.googlecode.phpreboot.interpreter.Evaluator.visit(Evaluator.java:1) at com.googlecode.phpreboot.ast.InstrLabeled.accept(InstrLabeled.java:38) at com.googlecode.phpreboot.interpreter.Evaluator.eval(Evaluator.java:188) at com.googlecode.phpreboot.interpreter.Interpreter.eval(Interpreter.java:69) at com.googlecode.phpreboot.interpreter.Interpreter.instr_labeled(Interpreter.java:307) at com.googlecode.phpreboot.tools.AnalyzerProcessor.reduce(AnalyzerProcessor.java:729) at com.googlecode.phpreboot.tools.AnalyzerProcessor.reduce(AnalyzerProcessor.java:1) at fr.umlv.tatoo.runtime.tools.ToolsProcessor.reduce(ToolsProcessor.java:117) at fr.umlv.tatoo.runtime.parser.Parser.performReduce(Parser.java:484) at fr.umlv.tatoo.runtime.parser.Parser.performShift(Parser.java:508) at fr.umlv.tatoo.runtime.parser.ShiftAction.doPerform(ShiftAction.java:23) at fr.umlv.tatoo.runtime.parser.Parser.doStep(Parser.java:402) at fr.umlv.tatoo.runtime.parser.Parser.push(Parser.java:384) at fr.umlv.tatoo.runtime.tools.ToolsProcessor$LexerHandler.ruleVerified(ToolsProcessor.java:87) at fr.umlv.tatoo.runtime.tools.ToolsProcessor$LexerHandler.ruleVerified(ToolsProcessor.java:67) at fr.umlv.tatoo.runtime.lexer.Lexer$LexerImpl.ruleVerified(Lexer.java:141) at fr.umlv.tatoo.runtime.lexer.Lexer$LexerImpl.step(Lexer.java:86) at fr.umlv.tatoo.runtime.lexer.Lexer$LexerImpl.run(Lexer.java:155) at com.googlecode.phpreboot.interpreter.Analyzer.analyze(Analyzer.java:82) at com.googlecode.phpreboot.Main.main(Main.java:176) Caused by: java.lang.UnsupportedOperationException: NYI at sun.dyn.FromGeneric.buildAdapterFromBytecodes(FromGeneric.java:238) at sun.dyn.FromGeneric.(FromGeneric.java:95) at sun.dyn.FromGeneric.of(FromGeneric.java:182) at sun.dyn.FromGeneric.make(FromGeneric.java:174) at sun.dyn.MethodHandleImpl.convertArguments(MethodHandleImpl.java:804) at java.dyn.MethodHandles.convertArguments(MethodHandles.java:1021) at sun.dyn.Invokers.genericInvoker(Invokers.java:78) at sun.dyn.Invokers.varargsInvoker(Invokers.java:86) at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:364) at com.googlecode.phpreboot.compil From john.r.rose at oracle.com Sun May 23 20:54:24 2010 From: john.r.rose at oracle.com (John Rose) Date: Sun, 23 May 2010 20:54:24 -0700 Subject: InvokeVarargs with a method with more than 10 arguments In-Reply-To: <4BF9A59F.7090706@univ-mlv.fr> References: <4BF9A59F.7090706@univ-mlv.fr> Message-ID: <28920E7C-8018-4CB2-B504-3EC6A387CC0C@oracle.com> Working on this; the next big chunk removes such limitations. (Ricochet frames.) -- John On May 23, 2010, at 3:01 PM, R?mi Forax wrote: > I got a NYI if I try to call a method using invokeVarargs with more than > 10 arguments. From forax at univ-mlv.fr Mon May 24 03:04:53 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 24 May 2010 12:04:53 +0200 Subject: InvokeVarargs with a method with more than 10 arguments In-Reply-To: <28920E7C-8018-4CB2-B504-3EC6A387CC0C@oracle.com> References: <4BF9A59F.7090706@univ-mlv.fr> <28920E7C-8018-4CB2-B504-3EC6A387CC0C@oracle.com> Message-ID: <4BFA4F45.7000403@univ-mlv.fr> Le 24/05/2010 05:54, John Rose a ?crit : > Working on this; the next big chunk removes such limitations. (Ricochet frames.) -- John > Ok, cool. R?mi > On May 23, 2010, at 3:01 PM, R?mi Forax wrote: > > >> I got a NYI if I try to call a method using invokeVarargs with more than >> 10 arguments. >> > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From john.r.rose at oracle.com Mon May 24 12:57:43 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 24 May 2010 12:57:43 -0700 Subject: Sv: hg: mlvm/mlvm/jdk: cpindex: reorder series file to reflect recent and pending pushes; tweak MethodHandlesTest In-Reply-To: <68a0e60c-38b5-4c6c-827f-08e5105650dc@default> References: <68a0e60c-38b5-4c6c-827f-08e5105650dc@default> Message-ID: <488D4A29-4EB6-4570-81CA-E1BA3272C81B@oracle.com> On May 23, 2010, at 10:21 AM, Fredrik ?hrstr?m wrote: > What are the patches needed to build > with full MethodHandle support. > The wiki page http://wikis.sun.com/display/mlvm/Building > > says that the patche guards "buildable testable" > should be used. > > This is clearly not enough. It seems like 6939203 and > at least something more is needed. > > What are the exact patches needed for full MethodHandle support? If you look in the .hg/patches/series file you'll see a comment about the base revision for the patches (for 292 work). That also has to be a guard. It's an extra check to make sure people don't accidentally apply patches to a random base revision. Here are the exact guards that currently will push all applicable 292 patches: hg qsel d6d1af32c5f9 buildable testable I also add these, just to keep sub-projects from mixing by accident: /hotswap /callcc /tailc /inti /anont /coro . The hex number changes every time we rebase the patches. The commands in the wiki obtain this number from current-release.sh. The "buildable testable" guards are there to exclude patches that are not ready. In other words, they act only negatively: "#-buildable", etc. Currently, dynopt-6912064.patch is disabled with "#-testable" because it failed a regression test and I haven't looked into it yet. In Mercurial queues, negative guards are combined with "and", while positive guards are combined with "or". This makes negative guards much more useful. The guards that begin with "/" are double-negatives (my convention). Selecting "/coro" means "exclude coro", by convention. Marking a patch "-/coro" should be read as "if not excluding coro". -- John From john.r.rose at oracle.com Mon May 24 18:22:31 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 24 May 2010 18:22:31 -0700 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> Message-ID: <91B533BA-406B-4602-BE7B-C9F0669B53BC@oracle.com> On May 18, 2010, at 1:18 PM, Charles Oliver Nutter wrote: > One important question for me is how multi-method interfaces would be > handled. I had originally tried to use Scala's "Function" interfaces > in Duby to represent closures, but they all have multiple abstract > methods that must be handled completely differently. Right. Here are the degrees of freedom I see at this point: - whether to accept SAM types which are not interfaces (default: yes) - whether to allow a query API for recovering a method handle from a proxy (default: yes) - whether to allow multiple methods to be associated with multiple MHs (default: no) - whether to allow multiple super types in the proxy object (default: no) - whether multiple methods must be individually closed, or can be mutually closed over another value The reason I "stopped at one" is there are more optimization options for the simplified case of one-type-one-method. Also, the query API in point 2 is harder to get right if you accept the other points. But I do agree there should be a mechanism supporting the additional degrees of freedom. It needs to be bulkier, though. It probably needs multiple phases, like a builder. Also, the various parts (methods, receivers) can appear at various times. Here's a two-phase version: class InstanceBuilder { InstanceBuilder(List> supers, List names, List types); InstanceBuilder(List> supers, List names, List types, Class receiver); InstanceBuilder(List> supers, List names, List methods); T newInstance(R receiver, MethodHandle... methods); T newInstance(MethodHandle... methods); // no bound receiver T newInstance(R receiver); // previously specified methods } Here's chained multi-phase version: class InstanceBuilder { InstanceBuilder(List> supers, List names, List types); InstanceBuilder bindReceiver(R receiver); InstanceBuilder bindMethod(String name, MethodHandle method); T newInstance(); } And so on... > I'd need to > provide my own superclass with default behavior or have a way to > stitch together N handles for N abstract methods. > > And I agree about the language bridging...plus in the JRuby case, this > actually makes Ruby to Ruby bridging easier: > > * We need a codebase that works on Java 6 > * ...so we can't move our entire call path to using MethodHandle > * ...so we need our own abstract "invoker" supertype > * ...so being able to use that supertype with either generated impls > or MethodHandle-provided impls makes it easier for us to support both > indy and non-indy runtimes in the same implementation. Wrapping method handles adds layers of indirection and boxing hazards as Remi points out. An unsolved problem with JSR 292 is how to mix method handles in with other supertypes. An excellent solution would allow you to define your own supertypes and APIs, and have them more or less directly mapped to method handles when method handles were available. This might increase the number of files which could be reused (just by recompilation or relinking) across JRuby implementations (indy or classic). I proposed JavaMethodHandle but as a fixed superclass it doesn't give much flexibility (not a mixin!). And it constrains JVM implementations too much to have an inheritable subtype of MethodHandle. Another possibility is to ask for an implicit conversion from selected application types X to MethodHandle. That in effect invents a new type relation: delegation. So it's no small matter. It's hard to keep that genie confined to a small bottle. > Perhaps this also helps Java 7 closures work nicer by making it > possible to have a generic Closure or Function superclass completely > independent of java.dyn? Or by making it possible to implement > (faster) Java reflection with fewer generic frames under the covers > via a single abstract supertype populated by indy? The best way I know to accelerate Java reflective invocation is this: java.lang.reflect.Method foo = ...; try { z = MethodHandles.unreflect(foo).invokeGeneric(a, b, c, ...); } catch { ... } For this to be faster, it assumes there is method handle caching on unreflect, which I haven't done. But could be done. For example, you could preserve source compatibility by making a wrapper method to hide MethodHandles. > Seems like a good addition, in any case, but especially once it's > faster and more direct than reflect.Proxy :) > > - Charlie > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From john.r.rose at oracle.com Mon May 24 19:33:13 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 25 May 2010 02:33:13 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: make ldc work for sparc Message-ID: <20100525023314.2FAB6445A3@hg.openjdk.java.net> Changeset: b8971823a6e4 Author: jrose Date: 2010-05-24 19:32 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b8971823a6e4 meth: make ldc work for sparc ! meth-ldc-6939203.patch From headius at headius.com Tue May 25 13:57:21 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 25 May 2010 15:57:21 -0500 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: <4BF30A2B.4080800@univ-mlv.fr> References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> <4BF30A2B.4080800@univ-mlv.fr> Message-ID: On Tue, May 18, 2010 at 4:44 PM, R?mi Forax wrote: > > [...] > >> One important question for me is how multi-method interfaces would be >> handled. I had originally tried to use Scala's "Function" interfaces >> in Duby to represent closures, but they all have multiple abstract >> methods that must be handled completely differently. I'd need to >> provide my own superclass with default behavior or have a way to >> stitch together N handles for N abstract methods. >> > > You can construct a tree of method handles, > like Attila's code does. I'm not sure I understand how this would tie into implementing an interface or abstract superclass with many methods...can you elaborate? > I think that you should maintain two codebases > (I am not kidding), > because to really unleash the power of JSR 292 > you have to use MethodHandle every where. > > If all your codebase use method handles, you > don't need boxing anymore along the whole path, ?you can > jump back and forth between the interpreter and the > runtime compiled code, you can share dynamic stubs > (by example the one you use to resolve the operator +) > between the interpreter and the runtime compiler, > and even try to share profiles between them > (I say try here because I have only a hackish solution) > etc. > > And you can do all of that with the few lines of codes > because the API allow you to work at a meta-level. I would honestly *love* to use indy everywhere; it would make my job as an implementer vastly simpler. But can the backport be used everywhere JRuby users will want to use JRuby? Can we, for example, generate code ahead of time for Google App Engine or Android, where we have no permission to hook into the root classloading process (or in the case of Android, where we can't even generate bytecode on-device)? I would throw out our current dispatch logic in a heartbeat if I knew it were possible to still support Java 5 and 6 with a single codebase, but frankly it's just not an option to make JRuby be Java 7-only right now when 7 isn't even out and we have production users. >> Perhaps this also helps Java 7 closures work nicer by making it >> possible to have a generic Closure or Function superclass completely >> independent of java.dyn? Or by making it possible to implement >> (faster) Java reflection with fewer generic frames under the covers >> via a single abstract supertype populated by indy? >> > > And your generic Closure/Function will be not a lot of > different from a method handle. Yes, this is also very true, and having all dispatch via method handles might make it easier for the JVM to see inlinable paths through closure-receiving bodies (where right now they go megamorphic and closures will never inline as a result...a major gap considering all the new languages want to use closures...) - Charlie From headius at headius.com Tue May 25 14:12:23 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Tue, 25 May 2010 16:12:23 -0500 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: <91B533BA-406B-4602-BE7B-C9F0669B53BC@oracle.com> References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> <91B533BA-406B-4602-BE7B-C9F0669B53BC@oracle.com> Message-ID: On Mon, May 24, 2010 at 8:22 PM, John Rose wrote: > On May 18, 2010, at 1:18 PM, Charles Oliver Nutter wrote: > >> One important question for me is how multi-method interfaces would be >> handled. I had originally tried to use Scala's "Function" interfaces >> in Duby to represent closures, but they all have multiple abstract >> methods that must be handled completely differently. > > Right. ?Here are the degrees of freedom I see at this point: > ?- whether to accept SAM types which are not interfaces (default: yes) > ?- whether to allow a query API for recovering a method handle from a proxy (default: yes) > ?- whether to allow multiple methods to be associated with multiple MHs (default: no) So you'd wire up a single handle that is dispatched through for all incoming cases? Similar to how we (and presumably Groovy, when there are no type hints) have a single JRuby "DynamicMethod" object for all overloads of a given method name, and it makes a selection based on actual types at runtime? > ?- whether to allow multiple super types in the proxy object (default: no) > ?- whether multiple methods must be individually closed, or can be mutually closed over another value > > The reason I "stopped at one" is there are more optimization options for the simplified case of one-type-one-method. > > Also, the query API in point 2 is harder to get right if you accept the other points. I don't have a particular need for the query API, though I haven't thought through the possibilities yet. For the most part, all I ever need is the implementation of some interface or abstract class, and after that it can "just" be a class to me. > But I do agree there should be a mechanism supporting the additional degrees of freedom. > > It needs to be bulkier, though. ?It probably needs multiple phases, like a builder. > > Also, the various parts (methods, receivers) can appear at various times. > > Here's a two-phase version: > ? class InstanceBuilder { > ? ? InstanceBuilder(List> supers, List names, List types); > ? ? InstanceBuilder(List> supers, List names, List types, Class receiver); > ? ? InstanceBuilder(List> supers, List names, List methods); > ? ? T newInstance(R receiver, MethodHandle... methods); > ? ? T newInstance(MethodHandle... methods); // no bound receiver > ? ? T newInstance(R receiver); // previously specified methods > ? } > > Here's chained multi-phase version: > ? class InstanceBuilder { > ? ? InstanceBuilder(List> supers, List names, List types); > ? ? InstanceBuilder bindReceiver(R receiver); > ? ? InstanceBuilder bindMethod(String name, MethodHandle method); > ? ? T newInstance(); > ? } > > And so on... Yeah, these seem like the right general direction. I'd probably my money behind the multi-phase, multi-call version. To add another use case to the Scala Function interfaces (which have multiple abstract methods): JRuby's own DynamicMethod has a number of call paths of different arities; if it were possible to implement all of them with handles we'd never have to generate another "invoker" again. > Wrapping method handles adds layers of indirection and boxing hazards as Remi points out. To be sure...I'd love to move back into the realm of having no users and JRuby being in its early research days, so I could commit to being Java 7-only. It would make meeting performance challenges a vastly simpler proposition. Unfortunately that's pretty hard to justify right now, when we're busy trying to get paying customers (who stubbornly refuse to use trunk builds of MLVM...imagine the nerve!). :) > An unsolved problem with JSR 292 is how to mix method handles in with other supertypes. ?An excellent solution would allow you to define your own supertypes and APIs, and have them more or less directly mapped to method handles when method handles were available. ?This might increase the number of files which could be reused (just by recompilation or relinking) across JRuby implementations (indy or classic). My current solution for that is infeasible given time and resources: mutually-incompatible call paths loaded conditionally if you're running on Java 7. > I proposed JavaMethodHandle but as a fixed superclass it doesn't give much flexibility (not a mixin!). ?And it constrains JVM implementations too much to have an inheritable subtype of MethodHandle. Yes, having a java.dyn supertype doesn't help us reuse code from non-indy builds. It certainly makes it easier to implement complicated handle logic (assuming that code gets specialized for each inline location...which I'm not sure of right now), but that's firmly indy-specific. > Another possibility is to ask for an implicit conversion from selected application types X to MethodHandle. ?That in effect invents a new type relation: delegation. ?So it's no small matter. ?It's hard to keep that genie confined to a small bottle. Being able to generate subclasses would definitely be the more straightforward option here; we don't really care about the actual type of *any* of our generated DynamicMethod subtypes...we just need a way to stitch calls from A to B through a known interface without defeating inlining. >> Perhaps this also helps Java 7 closures work nicer by making it >> possible to have a generic Closure or Function superclass completely >> independent of java.dyn? Or by making it possible to implement >> (faster) Java reflection with fewer generic frames under the covers >> via a single abstract supertype populated by indy? > > The best way I know to accelerate Java reflective invocation is this: > ? ? ? ?java.lang.reflect.Method foo = ...; > ? ? ? ?try { z = MethodHandles.unreflect(foo).invokeGeneric(a, b, c, ...); } > ? ? ? ?catch { ... } > > For this to be faster, it assumes there is method handle caching on unreflect, which I haven't done. ?But could be done. > > For example, you could preserve source compatibility by making a wrapper method to hide MethodHandles. This would be similar to us lazily generating a direct handle object for each reflected method, which we currently support but don't turn on by default. In our case, there's an explosion of user-loaded classes to deal with, as well as the stickiness of loading custom classes that reference classes you might want to unload later...back to the ClassLoader hard reference issue again. But your trick is cleaner; we could potentially have a separate branch that goes out to indy code if it's around, and that indy code would use this logic. The ideal case would be that both indy and non-indy dispatch through the same interface...and then we're back to needing a way to implement an interface entirely with method handles again :) - Charlie From forax at univ-mlv.fr Wed May 26 05:48:42 2010 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 26 May 2010 14:48:42 +0200 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> <4BF30A2B.4080800@univ-mlv.fr> Message-ID: <4BFD18AA.7030007@univ-mlv.fr> Le 25/05/2010 22:57, Charles Oliver Nutter a ?crit : > >> I think that you should maintain two codebases >> (I am not kidding), >> because to really unleash the power of JSR 292 >> you have to use MethodHandle every where. >> >> If all your codebase use method handles, you >> don't need boxing anymore along the whole path, you can >> jump back and forth between the interpreter and the >> runtime compiled code, you can share dynamic stubs >> (by example the one you use to resolve the operator +) >> between the interpreter and the runtime compiler, >> and even try to share profiles between them >> (I say try here because I have only a hackish solution) >> etc. >> >> And you can do all of that with the few lines of codes >> because the API allow you to work at a meta-level. >> > I would honestly *love* to use indy everywhere; it would make my job > as an implementer vastly simpler. But can the backport be used > everywhere JRuby users will want to use JRuby? Can we, for example, > generate code ahead of time for Google App Engine or Android, where we > have no permission to hook into the root classloading process (or in > the case of Android, where we can't even generate bytecode on-device)? > You can compile ahead, that's not what the backport does, and you will face the same problem that JRuby currently have. You will have to generate lot of stubs that will need to be included in the dex file. > I would throw out our current dispatch logic in a heartbeat if I knew > it were possible to still support Java 5 and 6 with a single codebase, > but frankly it's just not an option to make JRuby be Java 7-only right > now when 7 isn't even out and we have production users. > As I previously says, you should maintain two code bases. > >>> Perhaps this also helps Java 7 closures work nicer by making it >>> possible to have a generic Closure or Function superclass completely >>> independent of java.dyn? Or by making it possible to implement >>> (faster) Java reflection with fewer generic frames under the covers >>> via a single abstract supertype populated by indy? >>> >>> >> And your generic Closure/Function will be not a lot of >> different from a method handle. >> > Yes, this is also very true, and having all dispatch via method > handles might make it easier for the JVM to see inlinable paths > through closure-receiving bodies (where right now they go megamorphic > and closures will never inline as a result...a major gap considering > all the new languages want to use closures...) > > - Charlie > R?mi From szegedia at gmail.com Wed May 26 06:05:16 2010 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 26 May 2010 15:05:16 +0200 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> <4BF30A2B.4080800@univ-mlv.fr> Message-ID: <89808365-F7C7-4301-93F5-9DDFE1CD802F@gmail.com> On 2010.05.25., at 22:57, Charles Oliver Nutter wrote: > On Tue, May 18, 2010 at 4:44 PM, R?mi Forax wrote: >> >> [...] >> >>> One important question for me is how multi-method interfaces would be >>> handled. I had originally tried to use Scala's "Function" interfaces >>> in Duby to represent closures, but they all have multiple abstract >>> methods that must be handled completely differently. I'd need to >>> provide my own superclass with default behavior or have a way to >>> stitch together N handles for N abstract methods. >>> >> >> You can construct a tree of method handles, >> like Attila's code does. > > I'm not sure I understand how this would tie into implementing an > interface or abstract superclass with many methods...can you > elaborate? Honestly, I can't work out either what's R?mi referring to :-) Attila. From forax at univ-mlv.fr Wed May 26 07:14:57 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 26 May 2010 16:14:57 +0200 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: <89808365-F7C7-4301-93F5-9DDFE1CD802F@gmail.com> References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> <4BF30A2B.4080800@univ-mlv.fr> <89808365-F7C7-4301-93F5-9DDFE1CD802F@gmail.com> Message-ID: <4BFD2CE1.3010806@univ-mlv.fr> Le 26/05/2010 15:05, Attila Szegedi a ?crit : > On 2010.05.25., at 22:57, Charles Oliver Nutter wrote: > > >> On Tue, May 18, 2010 at 4:44 PM, R?mi Forax wrote: >> >>> [...] >>> >>> >>>> One important question for me is how multi-method interfaces would be >>>> handled. I had originally tried to use Scala's "Function" interfaces >>>> in Duby to represent closures, but they all have multiple abstract >>>> methods that must be handled completely differently. I'd need to >>>> provide my own superclass with default behavior or have a way to >>>> stitch together N handles for N abstract methods. >>>> >>>> >>> You can construct a tree of method handles, >>> like Attila's code does. >>> >> I'm not sure I understand how this would tie into implementing an >> interface or abstract superclass with many methods...can you >> elaborate? >> > Honestly, I can't work out either what's R?mi referring to :-) > > Attila. > I don't remember too. Anyway, you don't have to implement all the methods, one is sufficient if you can garantee that there is a surjection between the set of possible signatures and the set of possible methods. R?mi From john.r.rose at oracle.com Wed May 26 11:16:10 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Wed, 26 May 2010 18:16:10 +0000 Subject: hg: mlvm/mlvm/hotspot: cpindex: match final push to hotspot-comp Message-ID: <20100526181611.DF6D446E2D@hg.openjdk.java.net> Changeset: 5488c60a0695 Author: jrose Date: 2010-05-26 11:14 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5488c60a0695 cpindex: match final push to hotspot-comp ! cpindex-6939207.patch From john.r.rose at oracle.com Thu May 27 14:41:18 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Thu, 27 May 2010 21:41:18 +0000 Subject: hg: mlvm/mlvm/hotspot: cpindex: match final push to hotspot-comp (of bugfix 6956164) Message-ID: <20100527214119.5588746E4B@hg.openjdk.java.net> Changeset: 7c5fa4ea1fa5 Author: jrose Date: 2010-05-27 14:37 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/7c5fa4ea1fa5 cpindex: match final push to hotspot-comp (of bugfix 6956164) + cpindex-6956164.patch ! series From john.r.rose at oracle.com Thu May 27 18:39:51 2010 From: john.r.rose at oracle.com (John Rose) Date: Thu, 27 May 2010 18:39:51 -0700 Subject: hg: mlvm/mlvm/jdk: meth: add proxy maker for closures In-Reply-To: References: <20100518073523.9979544F7B@hg.openjdk.java.net> <4BF248E4.9070805@univ-mlv.fr> <91B533BA-406B-4602-BE7B-C9F0669B53BC@oracle.com> Message-ID: <935F07A4-CD6E-4786-8B4B-2BD019512A97@oracle.com> On May 25, 2010, at 2:12 PM, Charles Oliver Nutter wrote: > On Mon, May 24, 2010 at 8:22 PM, John Rose wrote: >> Right. Here are the degrees of freedom I see at this point: >> - whether to accept SAM types which are not interfaces (default: yes) >> - whether to allow a query API for recovering a method handle from a proxy (default: yes) >> - whether to allow multiple methods to be associated with multiple MHs (default: no) > > So you'd wire up a single handle that is dispatched through for all > incoming cases? Similar to how we (and presumably Groovy, when there > are no type hints) have a single JRuby "DynamicMethod" object for all > overloads of a given method name, and it makes a selection based on > actual types at runtime? No, it would be some sort of marked tuple of method handles. The most concrete representation would be a pair of arrays: String[] and MethodHandle[]. Or it could be an interface CallResolver which, when queried with Class, String, and MethodType, gives a MethodHandle to call. You get best optimization when the CallResolver logic can be folded away for constant inputs. Forcing all calls to go through a single MH brings unrelated flows of control together, hurting optimization. >> Also, the query API in point 2 is harder to get right if you accept the other points. > > I don't have a particular need for the query API, though I haven't > thought through the possibilities yet. For the most part, all I ever > need is the implementation of some interface or abstract class, and > after that it can "just" be a class to me. The query API would allow the wrapper to be unwrapped directly. This is useful if you are ping-ponging the same value between modules that expect a MH or expect a wrapper. You can unwrap by binding one of the wrapper's methods to the wrapper, but it is likely that implementations would produce an ever-lengthening chain of MH indirections, one link for each wrap or unwrap step. That seems like a performance hazard to me. It is likely people will want to decorate method handles with many additional APIs. (That's what JMH was for.) If we have a standard interface AsMethodHandle or MethodHandleBox, then these decorated method handles can act much like subclassed objects of MH, since any MH-consuming API will work with a decorated MH, simply by calling MethodHandleBox.asMethodHandle. The explicit conversion call is clunkier than an implicit conversion to a supertype, but the effect is the same. >> Here's chained multi-phase version: >> class InstanceBuilder { >> InstanceBuilder(List> supers, List names, List types); >> InstanceBuilder bindReceiver(R receiver); >> InstanceBuilder bindMethod(String name, MethodHandle method); >> T newInstance(); >> } >> >> And so on... > > Yeah, these seem like the right general direction. I'd probably my > money behind the multi-phase, multi-call version. Probably the most credible alternative to an InstanceBuilder API is a CallResolver API (see above). I don't know how to choose between them... > To add another use case to the Scala Function interfaces (which have > multiple abstract methods): JRuby's own DynamicMethod has a number of > call paths of different arities; if it were possible to implement all > of them with handles we'd never have to generate another "invoker" > again. Well, you can do an adapter class right now. Is the lack of inlining stopping you? >> Wrapping method handles adds layers of indirection and boxing hazards as Remi points out. > > To be sure...I'd love to move back into the realm of having no users > and JRuby being in its early research days, so I could commit to being > Java 7-only. It would make meeting performance challenges a vastly > simpler proposition. Unfortunately that's pretty hard to justify right > now, when we're busy trying to get paying customers (who stubbornly > refuse to use trunk builds of MLVM...imagine the nerve!). :) Let's keep thinking about commoning up the 6 and 7 source lines. It seems to me that we ought to be able to do better. >> Another possibility is to ask for an implicit conversion from selected application types X to MethodHandle. That in effect invents a new type relation: delegation. So it's no small matter. It's hard to keep that genie confined to a small bottle. > > Being able to generate subclasses would definitely be the more > straightforward option here; we don't really care about the actual > type of *any* of our generated DynamicMethod subtypes...we just need a > way to stitch calls from A to B through a known interface without > defeating inlining. If you had more control over inlining, would you be able to make more architectural adjustments to co-adapt the source lines? Maybe it's time for the long-awaited @Inline directive. > >>> Perhaps this also helps Java 7 closures work nicer by making it >>> possible to have a generic Closure or Function superclass completely >>> independent of java.dyn? Or by making it possible to implement >>> (faster) Java reflection with fewer generic frames under the covers >>> via a single abstract supertype populated by indy? >> >> The best way I know to accelerate Java reflective invocation is this: >> java.lang.reflect.Method foo = ...; >> try { z = MethodHandles.unreflect(foo).invokeGeneric(a, b, c, ...); } >> catch { ... } >> >> For this to be faster, it assumes there is method handle caching on unreflect, which I haven't done. But could be done. >> >> For example, you could preserve source compatibility by making a wrapper method to hide MethodHandles. > > This would be similar to us lazily generating a direct handle object > for each reflected method, which we currently support but don't turn > on by default. In our case, there's an explosion of user-loaded > classes to deal with, as well as the stickiness of loading custom > classes that reference classes you might want to unload later...back > to the ClassLoader hard reference issue again. > > But your trick is cleaner; we could potentially have a separate branch > that goes out to indy code if it's around, and that indy code would > use this logic. The ideal case would be that both indy and non-indy > dispatch through the same interface...and then we're back to needing a > way to implement an interface entirely with method handles again :) If MHs.unreflect(foo) in the example above is your own API, then you can change the return value (in different builds) to get source compatibility: class RubyInvocables { static java.dyn.MethodHandle getInvocable(RubyMethod m) { ... } } // use: RubyInvocables.getInvocable(foo).invokeGeneric(a, b, c, ...); class RubyInvocables { static RubyInvocableInterface getInvocable(RubyMethod m) { ... } } interface RubyInvocableInterface { Object invokeGeneric(); Object invokeGeneric(Object a); Object invokeGeneric(Object a, Object b); Object invokeGeneric(Object a, Object b, Object c); Object invokeGeneric(Object a, Object b, Object c, Object... ds); } // use: RubyInvocables.getInvocable(foo).invokeGeneric(a, b, c, ...); -- John From john.r.rose at oracle.com Fri May 28 16:29:29 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Fri, 28 May 2010 23:29:29 +0000 Subject: hg: mlvm/mlvm/hotspot: cpindex: match final push to hotspot-comp (of bugfix 6957004) Message-ID: <20100528232929.B5BA246E88@hg.openjdk.java.net> Changeset: 8c1f208a4321 Author: jrose Date: 2010-05-28 16:29 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/8c1f208a4321 cpindex: match final push to hotspot-comp (of bugfix 6957004) ! cpindex-6956164.patch + cpindex-6957004.patch ! series From john.r.rose at oracle.com Fri May 28 18:50:58 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Sat, 29 May 2010 01:50:58 +0000 Subject: hg: mlvm/mlvm/hotspot: cpindex: clean out MethodComparator Message-ID: <20100529015058.3D06C46E92@hg.openjdk.java.net> Changeset: c4c888714efc Author: jrose Date: 2010-05-28 18:50 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c4c888714efc cpindex: clean out MethodComparator + cpindex-6957080.patch ! series From stephen.bannasch at deanbrook.org Sun May 30 08:31:22 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 30 May 2010 11:31:22 -0400 Subject: Mac OS X build available from 2010 05 28 Message-ID: FYI: I updated my Mac OS X mlvm build Friday and posted a tarball here: http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_05_28.tar.gz Built on 10.5.8. Here's the script I use to build it: http://gist.github.com/243072 $ /usr/local/java-1.7.0/bin/java -version openjdk version "1.7.0-internal" OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2010_05_28_19_48-b00) OpenJDK Server VM (build 18.0-b04, mixed mode) From stephen.bannasch at deanbrook.org Sun May 30 10:32:16 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Sun, 30 May 2010 13:32:16 -0400 Subject: hg: mlvm/mlvm/hotspot: cpindex: clean out MethodComparator In-Reply-To: <20100529015058.3D06C46E92@hg.openjdk.java.net> References: <20100529015058.3D06C46E92@hg.openjdk.java.net> Message-ID: now getting errors applying meth-ldc-6939203.patch cpindex-6957080 which came out after I last built Friday is being applied before meth-ldc-6939203 and they are both trying to replace this line in bytecode.cpp: return stdc == Bytecodes::_ldc ? get_index_u1(stdc) : get_index_u2(stdc); meth-ldc-6939203: Changeset: b8971823a6e4 Author: jrose Date: 2010-05-24 19:32 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b8971823a6e4 meth: make ldc work for sparc ! meth-ldc-6939203.patch cpindex-6957080.patch: Changeset: c4c888714efc Author: jrose Date: 2010-05-28 18:50 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c4c888714efc cpindex: clean out MethodComparator + cpindex-6957080.patch ! series This is what I get running: sh patches/make/each-patch-repo.sh "hg qpush -a" + (cd sources/hotspot; hg qpush -a) applying post-6939930-adjust.patch applying indy-sparc-6829193.patch applying meth-ing-6939134.patch applying meth-bcp-6939196.patch applying indy-c1-sparc-6930772.patch applying indy-c2-sparc-6934104.patch applying cpindex-6939207.patch applying cpindex-6956164.patch applying cpindex-6957004.patch applying cpindex-6957080.patch applying meth-ldc-6939203.patch patching file src/share/vm/interpreter/bytecode.cpp Hunk #1 FAILED at 210 1 out of 1 hunks FAILED -- saving rejects to file src/share/vm/interpreter/bytecode.cpp.rej patch failed, unable to continue (try -v) patch failed, rejects left in working dir errors during apply, please fix and refresh meth-ldc-6939203.patch *** Exit status 2. ---- file: bytecode.cpp.rej --- bytecode.cpp +++ bytecode.cpp @@ -211,11 +211,33 @@ } -// Implementation of Bytecodes loac constant +// Implementation of Bytecodes load constant + +int Bytecode_loadconstant::raw_index() const { + Bytecodes::Code rawc = code(); + if (rawc != Bytecodes::_wide) + return _bcp->get_index_u1(rawc); + rawc = Bytecodes::code_at(_bcp->addr_at(1)); + return _bcp->get_index_u2(rawc, true); +} int Bytecode_loadconstant::index() const { - Bytecodes::Code stdc = Bytecodes::java_code(code()); - return stdc == Bytecodes::_ldc ? get_index_u1(stdc) : get_index_u2(stdc); + int index = raw_index(); + if (has_cache_index()) { + return _method->constants()->cache()->entry_at(index)->constant_pool_index(); + } + return index; +} + +oop Bytecode_loadconstant::resolve_constant(TRAPS) const { + assert(_method.not_null(), "must supply method to resolve constant"); + int index = raw_index(); + constantPoolOop constants = _method->constants(); + if (has_cache_index()) { + return constants->resolve_cached_constant_at(index, THREAD); + } else { + return constants->resolve_constant_at(index, THREAD); + } } //------------------------------------------------------------------------------ From bodden at st.informatik.tu-darmstadt.de Mon May 31 09:18:24 2010 From: bodden at st.informatik.tu-darmstadt.de (Eric Bodden) Date: Mon, 31 May 2010 18:18:24 +0200 Subject: Mac OS X build available from 2010 05 28 In-Reply-To: <9711_1275289176_o4V6xaZf012386_p0624080ac828323a9af1@192.168.1.106> References: <9711_1275289176_o4V6xaZf012386_p0624080ac828323a9af1@192.168.1.106> Message-ID: Hi Stephen. Thanks a lot for your build. The binary works for me, but I am still having trouble building from source on Snow Leopard. I keep receiving the following error: /Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: In member function 'int LIR_Assembler::emit_unwind_handler()': /Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:472: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous /Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2189: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) /Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2191: note: void MacroAssembler::movptr(Address, RegisterImpl*) /Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:473: error: call of overloaded 'movptr(Address, int32_t)' is ambiguous /Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2189: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) /Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2191: note: void MacroAssembler::movptr(Address, RegisterImpl*) Any help would be greatly appreciated. Eric -- Dr. Eric Bodden Software Technology Group, Technische Universit?t Darmstadt, Germany Tel: +49 6151 16-5478 Fax: +49 6151 16-5410 Mailing Address: S2|02 A209, Hochschulstra?e 10, 64289 Darmstadt On 30 May 2010 17:31, Stephen Bannasch wrote: > FYI: I updated my Mac OS X mlvm build Friday and posted a tarball here: > > ? http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_05_28.tar.gz > > Built on 10.5.8. Here's the script I use to build it: http://gist.github.com/243072 > > ? $ /usr/local/java-1.7.0/bin/java -version > > ? openjdk version "1.7.0-internal" > ? OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2010_05_28_19_48-b00) > ? OpenJDK Server VM (build 18.0-b04, mixed mode) > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From headius at headius.com Mon May 31 10:41:37 2010 From: headius at headius.com (Charles Oliver Nutter) Date: Mon, 31 May 2010 12:41:37 -0500 Subject: Mac OS X build available from 2010 05 28 In-Reply-To: References: Message-ID: I'll make a shameless request, since you have a build env set up and I've been too lazy to refresh mine: can you post a fastdebug build too? I needz me opto assemblyz! On Sun, May 30, 2010 at 10:31 AM, Stephen Bannasch wrote: > FYI: I updated my Mac OS X mlvm build Friday and posted a tarball here: > > ? http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_05_28.tar.gz > > Built on 10.5.8. Here's the script I use to build it: http://gist.github.com/243072 > > ? $ /usr/local/java-1.7.0/bin/java -version > > ? openjdk version "1.7.0-internal" > ? OpenJDK Runtime Environment (build 1.7.0-internal-stephen_2010_05_28_19_48-b00) > ? OpenJDK Server VM (build 18.0-b04, mixed mode) > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From stephen.bannasch at deanbrook.org Mon May 31 15:43:59 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 31 May 2010 18:43:59 -0400 Subject: Mac OS X build available from 2010 05 28 In-Reply-To: References: <9711_1275289176_o4V6xaZf012386_p0624080ac828323a9af1@192.168.1.106> Message-ID: >Hi Stephen. > >Thanks a lot for your build. The binary works for me, but I am still >having trouble building from source on Snow Leopard. I keep receiving >the following error: > >/Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp: >In member function 'int LIR_Assembler::emit_unwind_handler()': >/Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:472: >error: call of overloaded 'movptr(Address, int32_t)' is ambiguous >/Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2189: >note: candidates are: void MacroAssembler::movptr(Address, intptr_t) >/Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2191: >note: void MacroAssembler::movptr(Address, >RegisterImpl*) >/Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/c1_LIRAssembler_x86.cpp:473: >error: call of overloaded 'movptr(Address, int32_t)' is ambiguous >/Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2189: >note: candidates are: void MacroAssembler::movptr(Address, intptr_t) >/Users/eric/jdk7/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2191: >note: void MacroAssembler::movptr(Address, >RegisterImpl*) > >Any help would be greatly appreciated. Hi Eric, I am by no means an expert on building mlvm ... and as of yesterday I can't build because meth-ldc-6939203.patch doesn't apply cleanly over cpindex-6957080.patch. Are you using my script for building? I have not yet used it on 10.6 but others on the list might have. Some general advice ... scan the earlier console output for errors or patches that didn't apply cleanly. When I built yesterday the process didn't actually halt from an error for quite a while even though the actual error was much earlier when the patch didn't apply cleanly (I could probably fix the script so when that happened it stopped earlier). From stephen.bannasch at deanbrook.org Mon May 31 16:34:52 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 31 May 2010 19:34:52 -0400 Subject: Mac OS X build available from 2010 05 28 In-Reply-To: References: Message-ID: At 12:41 PM -0500 5/31/10, Charles Oliver Nutter wrote: >I'll make a shameless request, since you have a build env set up and >I've been too lazy to refresh mine: can you post a fastdebug build >too? I needz me opto assemblyz! Remind me (or point me to the info) about how to make a fastdebug build. I also need to learn how to easily move backwards in the mlvm patch repo because the tip didn't build for me yesterday (patch conflicts). I know how to do this in git but don't remember how in hg. From john.r.rose at oracle.com Mon May 31 18:29:56 2010 From: john.r.rose at oracle.com (John Rose) Date: Mon, 31 May 2010 18:29:56 -0700 Subject: Mac OS X build available from 2010 05 28 In-Reply-To: References: Message-ID: <98EDE505-3327-4763-89E3-D0D8AB701E9A@oracle.com> On May 31, 2010, at 4:34 PM, Stephen Bannasch wrote: > At 12:41 PM -0500 5/31/10, Charles Oliver Nutter wrote: >> I'll make a shameless request, since you have a build env set up and >> I've been too lazy to refresh mine: can you post a fastdebug build >> too? I needz me opto assemblyz! > > Remind me (or point me to the info) about how to make a fastdebug build. I think you can set SKIP_FASTDEBUG_BUILD=true on the original make command line (at the end of build.sh). It might also work to set "export SKIP_FASTDEBUG_BUILD=true" in the shell. You can also chdir into the build directory and build and test the JVM incrementally: $ cd $DAVINCI/sources $ export JAVA_BUILD=$(cd build/bsd-i586/j2sdk-image; pwd -P) $ cd build/bsd-i586/hotspot/outputdir/bsd_i486_compiler2/fastdebug $ make $ alias gamma='JAVA_HOME=$JAVA_BUILD DYLD_LIBRARY_PATH=. ./gamma' $ gamma Queens #etc. > I also need to learn how to easily move backwards in the mlvm patch repo because the tip didn't build for me yesterday (patch conflicts). The "hg qpush" command manipulates the applied patch set. $ cd $DAVINCI/sources/hotspot $ hg qpop -a # pop all $ hg qpush meth-ldc-6939203.patch # push to that point $ hg qpop # pop one back Sorry about the mismatched patches. I did a bunch of pushing to hotspot-comp last week and didn't clean up properly. Will fix shortly. -- John From john.r.rose at oracle.com Mon May 31 19:23:11 2010 From: john.r.rose at oracle.com (john.r.rose at oracle.com) Date: Tue, 01 Jun 2010 02:23:11 +0000 Subject: hg: mlvm/mlvm/hotspot: 2 new changesets Message-ID: <20100601022312.DC50146EA8@hg.openjdk.java.net> Changeset: 371913893726 Author: jrose Date: 2010-05-31 17:56 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/371913893726 cpindex: match final push to hotspot-comp (of bugfix 6957080) ! cpindex-6957080.patch Changeset: a31a444c29a8 Author: jrose Date: 2010-05-31 19:22 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a31a444c29a8 meth: update ldc patch ! meth-ldc-6939203.patch From stephen.bannasch at deanbrook.org Mon May 31 20:34:50 2010 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Mon, 31 May 2010 23:34:50 -0400 Subject: Mac OS X build available from 2010 05 28 In-Reply-To: <98EDE505-3327-4763-89E3-D0D8AB701E9A@oracle.com> References: <98EDE505-3327-4763-89E3-D0D8AB701E9A@oracle.com> Message-ID: Thanks for the tips John, >On May 31, 2010, at 4:34 PM, Stephen Bannasch wrote: > >> At 12:41 PM -0500 5/31/10, Charles Oliver Nutter wrote: >>> I'll make a shameless request, since you have a build env set up and >>> I've been too lazy to refresh mine: can you post a fastdebug build >>> too? I needz me opto assemblyz! >> >> Remind me (or point me to the info) about how to make a fastdebug build. > >I think you can set SKIP_FASTDEBUG_BUILD=true on the original make command line (at the end of build.sh). > >It might also work to set "export SKIP_FASTDEBUG_BUILD=true" in the shell. OK, in my build script (update.sh at http://gist.github.com/243072) where I set the variable 'sets' I've added: DEBUG_NAME=fastdebug SKIP_FASTDEBUG_BUILD=true I find the name SKIP_FASTDEBUG_BUILD confusing if setting it to true causes the build to be a 'fastdebug' build -- seems 'skip'means the opposite would be true. How can I tell if I've created a fastdebug build? >You can also chdir into the build directory and build and test the JVM incrementally: > $ cd $DAVINCI/sources > $ export JAVA_BUILD=$(cd build/bsd-i586/j2sdk-image; pwd -P) > $ cd build/bsd-i586/hotspot/outputdir/bsd_i486_compiler2/fastdebug > $ make > $ alias gamma='JAVA_HOME=$JAVA_BUILD DYLD_LIBRARY_PATH=. ./gamma' > $ gamma Queens #etc. > >> I also need to learn how to easily move backwards in the mlvm patch repo because the tip didn't build for me yesterday (patch conflicts). > >The "hg qpush" command manipulates the applied patch set. > $ cd $DAVINCI/sources/hotspot > $ hg qpop -a # pop all > $ hg qpush meth-ldc-6939203.patch # push to that point > $ hg qpop # pop one back > >Sorry about the mismatched patches. I did a bunch of pushing to hotspot-comp last week and didn't clean up properly. Will fix shortly. I tried just commenting out cpindex-6957080.patch in patches/hotspot/series # cpindex-6957080.patch #-/meth #+d6d1af32c5f9 and that seemed to work. *** but I see you just updated the patches so tip compiles again, thanks ;-) $ ./build/bsd-i586/j2sdk-image/bin/java -version openjdk version "1.7.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.7.0-internal-fastdebug-stephen_2010_05_31_22_38-b00) OpenJDK Server VM (build 18.0-b04-fastdebug, mixed mode) I just finished uploading a new build (hopefully one built w/fastdebug) here: http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_05_31.tar.gz From bodden at st.informatik.tu-darmstadt.de Mon May 31 23:10:51 2010 From: bodden at st.informatik.tu-darmstadt.de (Eric Bodden) Date: Tue, 1 Jun 2010 08:10:51 +0200 Subject: Mac OS X build available from 2010 05 28 In-Reply-To: References: <9711_1275289176_o4V6xaZf012386_p0624080ac828323a9af1@192.168.1.106> Message-ID: Hi Stephen. > Are you using my script for building? Yes I am. > Some general advice ... scan the earlier console output for errors or patches that didn't apply cleanly. Ok, will do. Thanks! Eric