From charles.nutter at sun.com Fri Aug 1 11:08:01 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 01 Aug 2008 13:08:01 -0500 Subject: Symbolic freedom code + others, to live where? Message-ID: <48935101.60403@sun.com> I've finally gotten around to eliminating my own name-mangling code with John Rose's from the post "symbolic freedom in the VM" and had a practical question... Where should this live? For now I've copied it under a JRuby package, keeping all copyrights, etc intact, but it seems like this utility code ought to live somewhere other than directly in my codebase. I imagine any method handle or invokedynamic or whatever backports would need a home too. I'd humbly suggest the JVM Language Runtime project on Google Code, but it's certainly up for discussion. - Charlie From John.Rose at Sun.COM Mon Aug 4 14:51:07 2008 From: John.Rose at Sun.COM (John Rose) Date: Mon, 04 Aug 2008 14:51:07 -0700 Subject: what's John doing? In-Reply-To: <48923033.2050405@sun.com> References: <7c1bea4b0807210730m3e0ed9c4le486010d54b4888e@mail.gmail.com> <48923033.2050405@sun.com> Message-ID: <2DBD00A2-40D6-4795-A561-B89C260F1F8E@sun.com> On Jul 31, 2008, at 2:35 PM, Charles Oliver Nutter wrote: > At what point do you think > it would be worth trying to do an experimental test with e.g. JRuby, > wiring it in where reflection was being used previously? Here are the upcoming points of development for the native (non- emulated) JSR 292 RI: 1. direct emulation of invoke* instructions, interpreter only (first cut done & pushed) 2. adapter and bound method handles, interpreter only (working on this now) 3. invokedynamic (interpreter only) 4. compiler support for method handles 5. compiler support for invokedynamic 6. specialized call site optimizations (inlining) 7. specialized method handle optimizations (method handle compilation and/or folding) There are different advantages for integrating JRuby at each point. 1. can replace class generation for out-calls to Java (better footprint and bootstrap, but missing full performance until 6, 7) 2. can replace class generation pertaining to accessors, Ruby methods, linkage logic 3. can push linkage logic down into the JVM (more compact bytecode, slightly better performance, but missing full performance until 6, 7) 4, 5. performance improvement from steps 2, 3 6. meet or exceed current performance for hot paths 7. meet or exceed current performance for warm paths Early adoption is better, from my POV, but when you move in early you have to be willing to live with non-working appliances, construction noise, etc. To answer your specific question, you can almost replace reflection now, except for argument and return value transformations (adapting boxed varargs to native calling sequences). You could either wire up your own infrastructure for adapters to step 1 method handles, or wait for step 2 to provide you with VM-native adapters. I think the easiest way to do the adapters is to reflect argument lists up to (privileged) Java code, which will edit them in place on the interpreter stack. We'll see shortly if this works out. Backup plan is to put tons of new code into the JVM to handle all the corner cases of Integer.valueOf(int) and its dozens of cousins. -- John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20080804/d0d43546/attachment.html From lukas.stadler at jku.at Tue Aug 12 01:24:38 2008 From: lukas.stadler at jku.at (Lukas Stadler) Date: Tue, 12 Aug 2008 10:24:38 +0200 Subject: what's John doing? In-Reply-To: References: <7c1bea4b0807210730m3e0ed9c4le486010d54b4888e@mail.gmail.com> Message-ID: <48A148C6.4030306@jku.at> Hi John! I was looking at your method handle changeset and I was wondering if in the long run method handles will be serializable? Thinking about (serializable) continuations it would be very convenient if method handles would behave like java.lang.Class (which are serializable). Currently if you want to store a continuation you have to work around the fact that reflect.Method isn't serializable... - Lukas John Rose wrote: > Last Saturday around midnight the first method handle invocation went > through. It was a virtual call, equivalent to: > Object x = "foo"; > foo.toString(); > > See MethodHandleBytecodeTest.testToString in the push I just did: > http://hg.openjdk.java.net/mlvm/mlvm/hotspot/ > > Next up, adapter method handles. > > -- John > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From John.Rose at Sun.COM Tue Aug 12 15:21:49 2008 From: John.Rose at Sun.COM (John Rose) Date: Tue, 12 Aug 2008 15:21:49 -0700 Subject: serializing continuations, security issues In-Reply-To: <48A148C6.4030306@jku.at> References: <7c1bea4b0807210730m3e0ed9c4le486010d54b4888e@mail.gmail.com> <48A148C6.4030306@jku.at> Message-ID: <3457779A-6321-4C95-A7C3-45E242F22FEF@Sun.COM> On Aug 12, 2008, at 1:24 AM, Lukas Stadler wrote: > I was looking at your method handle changeset and I was wondering > if in the long run method handles will be serializable? > Thinking about (serializable) continuations it would be very > convenient if method handles would behave like java.lang.Class > (which are serializable). Interesting point. Here's the catch: A method handle is a capability to call the method, even if it is not public. If it were simply serializable, it would be easy to forge capabilities to private members. A reflective method with the accessible bit set is also such a capability, so there's a similar argument there. > Currently if you want to store a continuation you have to work > around the fact that reflect.Method isn't serializable... Right. As you know, this is one of the challenges working with continuations: You get the interior state of a computation, some of which may be private to a class, and you don't want to open up a security hole by allowing untrusted parties to inspect the contents of that state via a serialization, or (much worse) to forge similar states by editing serialized continuations. What we need is a way for trusted parties to serialize the method (and other continuation parts) with the understanding that the serializations will be kept private, or at least sanitized when exiting trust boundaries, and verified when entering them. For method handles, this means we need at least a partial reflection API for them. Currently, for direct method handles only, you can get their type (which is public anyway) and the method name as a string. I'm not concentrating on such an API, since it is not necessary to making invokedynamic a success, but it will have to be thrashed out at some point. Thanks for thinking about this! -- John From John.Rose at Sun.COM Tue Aug 12 15:22:21 2008 From: John.Rose at Sun.COM (John Rose) Date: Tue, 12 Aug 2008 15:22:21 -0700 Subject: what's John doing? In-Reply-To: <48A148C6.4030306@jku.at> References: <7c1bea4b0807210730m3e0ed9c4le486010d54b4888e@mail.gmail.com> <48A148C6.4030306@jku.at> Message-ID: FTR, I'm working on bound method handles now; they should be ready to push soon. I am temporarily avoiding VM-supported adapters, since they can be simulated by bound method handles plus (ugly) signature adapters written in Java bytecodes. The goal, of course, is to get a sub-optimal invokedynamic working sooner rather than later. -- John From john.rose at sun.com Sat Aug 16 01:32:36 2008 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 16 Aug 2008 08:32:36 +0000 Subject: hg: mlvm/mlvm/hotspot: 5 new changesets Message-ID: <20080816083236.CB82BD159@hg.openjdk.java.net> Changeset: a421ed0ab619 Author: jrose Date: 2008-08-15 23:49 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a421ed0ab619 tweak API ! anonk.patch Changeset: 8610ea7f96a6 Author: jrose Date: 2008-08-15 23:51 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/8610ea7f96a6 meth: direct and bound method handles work ! meth.patch Changeset: 16e7bac86f4c Author: jrose Date: 2008-08-16 00:31 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/16e7bac86f4c move annot past meth ! series Changeset: 00ab99cf1d52 Author: jrose Date: 2008-08-16 01:30 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/00ab99cf1d52 meth: update project file factor sources into the JDK repository, where they belong ! meth.proj.patch Changeset: e205623138c2 Author: jrose Date: 2008-08-16 01:31 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/e205623138c2 anonk: create project file for testing anonk feature standalone + anonk.proj.patch From john.rose at sun.com Sat Aug 16 01:32:51 2008 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 16 Aug 2008 08:32:51 +0000 Subject: hg: mlvm/mlvm/jdk: 2 new changesets Message-ID: <20080816083251.B3FA6D15E@hg.openjdk.java.net> Changeset: 308f0b343095 Author: jrose Date: 2008-08-16 00:17 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/308f0b343095 anonk: formal API for constant pool patching Contributed-By: Remi Forax, jrose Reviewed-by: jrose ! anonk.patch Changeset: 91eaa4180af4 Author: jrose Date: 2008-08-16 00:27 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/91eaa4180af4 meth: 6655638: dynamic languages need method handles Summary: MethodHandle and related types, precursor to invokedynamic Requires JVM runtime support from changeset 8610ea7f96a6 in ../hotspot Includes initial cut of invokedynamic APIs derived from JSR 292 EDR. Reviewed-by: jrose + meth.patch ! series From John.Rose at Sun.COM Sat Aug 16 01:46:14 2008 From: John.Rose at Sun.COM (John Rose) Date: Sat, 16 Aug 2008 01:46:14 -0700 Subject: AnonymousClassLoader overhaul In-Reply-To: <480FA2E5.2000500@univ-mlv.fr> References: <480F1A6A.4020302@univ-mlv.fr> <480FA2E5.2000500@univ-mlv.fr> Message-ID: On Apr 23, 2008, at 1:58 PM, R?mi Forax wrote: > John Rose a ?crit : >> On Apr 23, 2008, at 4:15 AM, R?mi Forax wrote: >> >>> The source code is available here: >>> http://www-igm.univ-mlv.fr/~forax/tmp/davinci-anonk.zip >>> >>> I've sent a previous message monday to the mlvm list but it seems it >>> was rejected because its size was too large (codes as attachment). >>> So i re-sent it now with a link. >>> >> >> Thanks, Remi. I've grabbed the file. I'll read it through ASAP. >> > Ok, let me know waht you want to change. > I will update the wiki when you will be ok with the implementation. Well, that took a long time, sorry. I started to use your revamped anonk code, was liking it, and started extending it for my (JSR 292 related) method handle development. I also adjusted some of the method splitting decisions; the Visitor ended up with a smaller, more regular set of methods. They surface the whole content of the CP, including internal references. I stubbed out an emulation mode, for when the JVM does not support anonk loading directly. Maybe there's a way to fold it together with the stuff in your Google repo. I pushed a bunch of stuff just now, including the method handle work. There are some Netbeans projects with a few unit tests. (NB 6.5 just came out. Great stuff.) -- John From John.Rose at Sun.COM Sat Aug 16 01:53:41 2008 From: John.Rose at Sun.COM (John Rose) Date: Sat, 16 Aug 2008 01:53:41 -0700 Subject: JVM Language Summit update Message-ID: <696CE246-6B9E-4471-B676-BBB9566CB068@sun.com> Hello, colleagues. There is new content on the website for next month's JVM Language Summit, including partial speaker lists and travel information. http://jvmlangsummit.com I hope to see you there! Best wishes, -- John From John.Rose at Sun.COM Tue Aug 26 02:07:35 2008 From: John.Rose at Sun.COM (John Rose) Date: Tue, 26 Aug 2008 02:07:35 -0700 Subject: Happy International Invokedynamic Day! Message-ID: On a modified JVM, a test program with more than one invokedynamic call site successfully linked, bootstrapped, and ran with the dynamically linked target methods. I declare August 26, 2008 as International Invokedynamic Day! -- John P.S. Enclosed is the demo program, with the winning output. It uses the anonymous class feature to wrangle bytecodes, but real users would rely on ASM or some such. -------------- next part -------------- A non-text attachment was scrubbed... Name: InvokeDynamicDemo.zip Type: application/zip Size: 3399 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20080826/2c542f47/attachment.zip From john.rose at sun.com Tue Aug 26 03:01:57 2008 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 26 Aug 2008 10:01:57 +0000 Subject: hg: mlvm/mlvm/hotspot: 3 new changesets Message-ID: <20080826100157.26E97DBAE@hg.openjdk.java.net> Changeset: 70401b91c4f7 Author: jrose Date: 2008-08-26 02:44 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/70401b91c4f7 meth: International Invokedynamic Day ! meth.patch Changeset: 15cb6a10af43 Author: jrose Date: 2008-08-26 03:00 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/15cb6a10af43 anonk: update test project to match sources ! anonk.proj.patch Changeset: b34dace3af6f Author: jrose Date: 2008-08-26 03:01 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b34dace3af6f meth: update test project to match sources ! meth.proj.patch From john.rose at sun.com Tue Aug 26 03:02:14 2008 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 26 Aug 2008 10:02:14 +0000 Subject: hg: mlvm/mlvm/jdk: 2 new changesets Message-ID: <20080826100215.0AA86DBB3@hg.openjdk.java.net> Changeset: c1b7e1b0d74a Author: jrose Date: 2008-08-26 02:42 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/c1b7e1b0d74a anonk: make CP patcher easier to use ! anonk.patch Changeset: 76dd10b26151 Author: jrose Date: 2008-08-26 02:44 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/76dd10b26151 meth: International Invokedynamic Day ! meth.patch From charles.nutter at sun.com Tue Aug 26 09:44:41 2008 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 26 Aug 2008 11:44:41 -0500 Subject: Happy International Invokedynamic Day! In-Reply-To: References: Message-ID: <48B432F9.6010905@sun.com> John Rose wrote: > On a modified JVM, a test program with more than one invokedynamic call > site successfully linked, bootstrapped, and ran with the dynamically > linked target methods. > > I declare August 26, 2008 as International Invokedynamic Day! > > -- John > > P.S. Enclosed is the demo program, with the winning output. > > It uses the anonymous class feature to wrangle bytecodes, but real users > would rely on ASM or some such. Awesome...and with JRuby 1.1.4 coming out today or tomorrow I'll be taking an invokdynamic vacation. Just in time to demo it for the fall conference season! - Charlie From Kenneth.Russell at Sun.COM Tue Aug 26 11:31:18 2008 From: Kenneth.Russell at Sun.COM (Kenneth Russell) Date: Tue, 26 Aug 2008 11:31:18 -0700 Subject: Happy International Invokedynamic Day! In-Reply-To: References: Message-ID: <48B44BF6.5030702@sun.com> John Rose wrote: > On a modified JVM, a test program with more than one invokedynamic call > site successfully linked, bootstrapped, and ran with the dynamically > linked target methods. > > I declare August 26, 2008 as International Invokedynamic Day! Excellent! A great leap forward for dynamic languages on the JVM. -Ken > -- John > > P.S. Enclosed is the demo program, with the winning output. > > It uses the anonymous class feature to wrangle bytecodes, but real users > would rely on ASM or some such. > > > ------------------------------------------------------------------------ > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From glaforge at gmail.com Tue Aug 26 12:09:12 2008 From: glaforge at gmail.com (Guillaume Laforge) Date: Tue, 26 Aug 2008 21:09:12 +0200 Subject: Happy International Invokedynamic Day! In-Reply-To: References: Message-ID: <197b18fc0808261209u28c96557va7e5aed2718aaedc@mail.gmail.com> Champaign! :-) On Tue, Aug 26, 2008 at 11:07 AM, John Rose wrote: > On a modified JVM, a test program with more than one invokedynamic call site > successfully linked, bootstrapped, and ran with the dynamically linked > target methods. > > I declare August 26, 2008 as International Invokedynamic Day! > > -- John > > P.S. Enclosed is the demo program, with the winning output. > > It uses the anonymous class feature to wrangle bytecodes, but real users > would rely on ASM or some such. > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > -- Guillaume Laforge Groovy Project Manager G2One, Inc. Vice-President Technology http://www.g2one.com From John.Rose at Sun.COM Tue Aug 26 16:26:37 2008 From: John.Rose at Sun.COM (John Rose) Date: Tue, 26 Aug 2008 16:26:37 -0700 Subject: Happy International Invokedynamic Day! In-Reply-To: <48B47668.6020702@Sun.COM> References: <48B47668.6020702@Sun.COM> Message-ID: <9193464F-6D9D-4190-80F4-5DD42F62B39E@Sun.COM> Thanks, Chuck, for elucidating the deep cultural context of this great day. It's only a matter of time before the TV shows, "American Code Monkey", and "So You Think You Can Hack". Nerds rule! -- John On Aug 26, 2008, at 2:32 PM, Chuck Rasbold wrote: > The Internet Anagram Server > > http://wordsmith.org/anagram/ > > confirmed "invokedynamic" as an anagram for > "da vinci monkey". Also, "yank vinci demo". > > > > The wikipedia entry for "code monkey": > > http://en.wikipedia.org/wiki/Code_monkey > > indicates that the term can be one of approbation, > which is how I meant it. I do appreciate Coulton's > song of the same name, though. > > > > And, you can buy "monkey da vinci" shirts here: > > http://www.cafepress.com/monomal/248379 > > > -- Chuck > > > John Rose wrote: >> FYI: An important JSR 292 milestone. -- John >> Begin forwarded message: >> *From: *John Rose > >> *Date: *August 26, 2008 2:07:35 AM PDT >> *To: *Da Vinci Machine Project > > >> *Subject: **Happy International Invokedynamic Day!* >> *Reply-To: *Da Vinci Machine Project > > >> On a modified JVM, a test program with more than one invokedynamic >> call site successfully linked, bootstrapped, and ran with the >> dynamically linked target methods. >> I declare August 26, 2008 as International Invokedynamic Day! >> -- John >> P.S. Enclosed is the demo program, with the winning output. >> It uses the anonymous class feature to wrangle bytecodes, but real >> users would rely on ASM or some such. >> --------------------------------------------------------------------- >> --- >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > From Dalibor.Topic at Sun.COM Wed Aug 27 05:21:49 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Wed, 27 Aug 2008 14:21:49 +0200 Subject: Happy International Invokedynamic Day! In-Reply-To: References: Message-ID: <48B546DD.3080003@Sun.COM> On 26/08/2008 11:07, John Rose wrote: > On a modified JVM, a test program with more than one invokedynamic > call site successfully linked, bootstrapped, and ran with the > dynamically linked target methods. Very, very cool - congrats, John! 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: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From john.rose at sun.com Fri Aug 29 15:30:43 2008 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 29 Aug 2008 22:30:43 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: fix initial bugs (GC, i2c, c2i transitions) Message-ID: <20080829223043.58873DF73@hg.openjdk.java.net> Changeset: 16ad46462338 Author: jrose Date: 2008-08-29 15:14 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/16ad46462338 meth: fix initial bugs (GC, i2c, c2i transitions) ! meth.patch From john.rose at sun.com Sat Aug 30 02:48:39 2008 From: john.rose at sun.com (john.rose at sun.com) Date: Sat, 30 Aug 2008 09:48:39 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: builds on x86/64, sparc Message-ID: <20080830094839.B8B9EDF8E@hg.openjdk.java.net> Changeset: cd9dcdc11080 Author: jrose Date: 2008-08-30 02:47 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/cd9dcdc11080 meth: builds on x86/64, sparc ! meth.patch From njriley at uiuc.edu Sat Aug 30 09:05:17 2008 From: njriley at uiuc.edu (Nicholas Riley) Date: Sat, 30 Aug 2008 11:05:17 -0500 Subject: hg: mlvm/mlvm/hotspot: meth: builds on x86/64, sparc - partial-fixes.patch (1/1) References: <20080830094839.B8B9EDF8E@hg.openjdk.java.net> Message-ID: In article <20080830094839.B8B9EDF8E at hg.openjdk.java.net>, john.rose at sun.com wrote: > Changeset: cd9dcdc11080 > Author: jrose > Date: 2008-08-30 02:47 -0700 > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/cd9dcdc11080 > > meth: builds on x86/64, sparc > > ! meth.patch I'm guessing this has only been tested on Solaris/Sun Studio? I tried building with GCC 3.4 and 4.1 on Linux and ran into this error with meth.patch applied: g++4 -DLINUX -D_GNU_SOURCE -DIA32 -DPRODUCT -I. -I../generated/adfiles -I../generated/jvmtifiles -I.../jdk7/hotspot/src/share/vm/asm -I.../jdk7/hotspot/src/share/vm/c1 -I.../jdk7/hotspot/src/share/vm/ci -I.../jdk7/hotspot/src/share/vm/classfile -I.../jdk7/hotspot/src/share/vm/code -I.../jdk7/hotspot/src/share/vm/compiler -I.../jdk7/hotspot/src/share/vm/gc_implementation -I.../jdk7/hotspot/src/share/vm/gc_implementation/parallelScavenge -I.../jdk7/hotspot/src/share/vm/gc_implementation/parNew -I.../jdk7/hotspot/src/share/vm/gc_implementation/shared -I.../jdk7/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I.../jdk7/hotspot/src/share/vm/gc_interface -I.../jdk7/hotspot/src/share/vm/interpreter -I.../jdk7/hotspot/src/share/vm/libadt -I.../jdk7/hotspot/src/share/vm/memory -I.../jdk7/hotspot/src/share/vm/oops -I.../jdk7/hotspot/src/share/vm/opto -I.../jdk7/hotspot/src/share/vm/prims -I.../jdk7/hotspot/src/share/vm/runtime -I.../jdk7/hotspot/src/share/vm/services -I.../jdk7/hotspot/src/share/vm/utilities -I.../jdk7/hotspot/src/cpu/x86/vm -I.../jdk7/hotspot/src/os/linux/vm -I.../jdk7/hotspot/src/os_cpu/linux_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"14.0-b03\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"njriley\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-njriley_2008_08_30_10_18-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DCOMPILER2 -DCOMPILER1 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -m32 -march=i586 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wconversion -Wsign-compare -c -o constantPoolKlass.o .../jdk7/hotspot/src/share/vm/oops/constantPoolKlass.cpp .../jdk7/hotspot/src/share/vm/gc_implementation/parNew/parOopClosures.inl ine.hpp: In member function 'void ParScanClosure::par_do_barrier(T*)': .../jdk7/hotspot/src/share/vm/gc_implementation/parNew/parOopClosures.inl ine.hpp:56: error: invalid use of undefined type 'struct CardTableRS' .../jdk7/hotspot/src/share/vm/memory/genOopClosures.hpp:27: error: forward declaration of 'struct CardTableRS' I got a bit lost with the header file generation so I wasn't sure how to fix it. (It seems Sun Studio isn't a supported compiler for OpenJDK on Linux as the build process tries to run cc with flags it doesn't understand.) A couple of minor fixes for GCC compatibility are attached. -- Nicholas Riley -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: partial-fixes.patch Url: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20080830/fb729c90/attachment.ksh From John.Rose at Sun.COM Sat Aug 30 15:23:41 2008 From: John.Rose at Sun.COM (John Rose) Date: Sat, 30 Aug 2008 15:23:41 -0700 Subject: hg: mlvm/mlvm/hotspot: meth: builds on x86/64, sparc - partial-fixes.patch (1/1) In-Reply-To: References: <20080830094839.B8B9EDF8E@hg.openjdk.java.net> Message-ID: <673DFD56-E1D4-4B96-80C4-9ACD6B2BE23E@sun.com> On Aug 30, 2008, at 9:05 AM, Nicholas Riley wrote: > I'm guessing this has only been tested on Solaris/Sun Studio? I tried > building with GCC 3.4 and 4.1 on Linux and ran into this error with > meth.patch applied: > Thanks for trying it out! You are right. The current prototype works (with bugs) on Solaris/x86/32 only. It builds (and works on standard programs) on other Solaris platforms but not yet on Windows or Linux. (I develop on a Solaris/VMware/MacBook/x86 stack, so that's what happens first.) Thanks for pointing out those problems with gcc compilability. There are similar problems on windows. I could use help with the sparc and x86/64 assembly code, too. If you would like to jump in, don't forget to sign the SCA https:// sca.dev.java.net/ . -- John From john.rose at sun.com Sat Aug 30 18:17:24 2008 From: john.rose at sun.com (john.rose at sun.com) Date: Sun, 31 Aug 2008 01:17:24 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: fix some build problems for JPRT Message-ID: <20080831011724.BDE74DF9C@hg.openjdk.java.net> Changeset: 0df7809c0e25 Author: jrose Date: 2008-08-30 18:16 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0df7809c0e25 meth: fix some build problems for JPRT ! meth.patch