From john.rose at sun.com Fri Apr 3 00:26:49 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 03 Apr 2009 07:26:49 +0000 Subject: hg: mlvm/mlvm/hotspot: indy: rebase to meth series and to bsd-port, redo opcode to be receiverless Message-ID: <20090403072649.7D881E1D0@hg.openjdk.java.net> Changeset: 84689b088293 Author: jrose Date: 2009-04-03 00:24 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/84689b088293 indy: rebase to meth series and to bsd-port, redo opcode to be receiverless ! indy.patch ! series From john.rose at sun.com Fri Apr 3 00:30:46 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 03 Apr 2009 07:30:46 +0000 Subject: hg: mlvm/mlvm/langtools: 2 new changesets Message-ID: <20090403073046.3BBF1E1DE@hg.openjdk.java.net> Changeset: cb6fe4452c67 Author: jrose Date: 2009-04-03 00:28 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/cb6fe4452c67 remove integrated patches - gibbons.patch - gibbons.txt Changeset: 274a81fa4e16 Author: jrose Date: 2009-04-03 00:28 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/274a81fa4e16 dyncast: buglet ! dyncast.patch From john.rose at sun.com Fri Apr 3 01:01:06 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 03 Apr 2009 08:01:06 +0000 Subject: hg: mlvm/mlvm/hotspot: meth, indy: rebase to bsd-port and latest JVM changes Message-ID: <20090403080106.DC9C4E1FF@hg.openjdk.java.net> Changeset: ef70a7045609 Author: jrose Date: 2009-04-03 00:59 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ef70a7045609 meth, indy: rebase to bsd-port and latest JVM changes ! tailc.txt From John.Rose at Sun.COM Fri Apr 3 02:33:13 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 03 Apr 2009 02:33:13 -0700 Subject: Latest instructions on getting and patching In-Reply-To: <49CFE1DB.8020507@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> Message-ID: Adjusting and testing the patch... Looks like it works. I found that this line in my top-level build.sh script helps when I am rebuilding the JVM from a non-clean forest: rm -f $(find build -name _precompiled.incl.gch) Also, because I'm not building the whole forest, this line seems to be required in build.sh also: ALT_JDK_IMPORT_PATH=/usr/local/soylatte16-i386-1.0.3 (same as ALT_BOOTDIR) -- John On Mar 29, 2009, at 2:02 PM, Charles Oliver Nutter wrote: > Charles Oliver Nutter wrote: >> To get the java.dyn.* classes included in rt.jar, I used Kirill's >> makefile patch. I've attached a version in "extended git" format >> which should apply cleanly. > > Forgot the patch... > > - Charlie > diff --git a/make/docs/CORE_PKGS.gmk b/make/docs/CORE_PKGS.gmk From john.rose at sun.com Fri Apr 3 02:36:40 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 03 Apr 2009 09:36:40 +0000 Subject: hg: mlvm/mlvm/jdk: meth, indy: rebase to bsd-port and latest JVM changes; pull indy changes out of meth Message-ID: <20090403093641.061EEE26D@hg.openjdk.java.net> Changeset: c3c0de253c82 Author: jrose Date: 2009-04-03 02:34 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/c3c0de253c82 meth, indy: rebase to bsd-port and latest JVM changes; pull indy changes out of meth ! indy.patch ! meth.patch ! series From john.rose at sun.com Fri Apr 3 02:55:52 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 03 Apr 2009 09:55:52 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: update test project Message-ID: <20090403095553.16533E274@hg.openjdk.java.net> Changeset: 3c642244cfb8 Author: jrose Date: 2009-04-03 02:53 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/3c642244cfb8 meth: update test project ! meth.proj.patch ! series From john.rose at sun.com Fri Apr 3 03:03:32 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 03 Apr 2009 10:03:32 +0000 Subject: hg: mlvm/mlvm/jdk: meth: remove spurious makefile change Message-ID: <20090403100333.094A5E279@hg.openjdk.java.net> Changeset: f1e1022079f2 Author: jrose Date: 2009-04-03 03:01 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f1e1022079f2 meth: remove spurious makefile change ! meth.patch From charles.nutter at sun.com Fri Apr 3 06:51:50 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 03 Apr 2009 08:51:50 -0500 Subject: Latest instructions on getting and patching In-Reply-To: References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> Message-ID: <49D61476.80705@sun.com> Excellent. I'll probably get things patched and try to do a test build today. Thanks John! John Rose wrote: > Adjusting and testing the patch... Looks like it works. > > I found that this line in my top-level build.sh script helps when I am > rebuilding the JVM from a non-clean forest: > rm -f $(find build -name _precompiled.incl.gch) > > Also, because I'm not building the whole forest, this line seems to be > required in build.sh also: > ALT_JDK_IMPORT_PATH=/usr/local/soylatte16-i386-1.0.3 (same as > ALT_BOOTDIR) > > -- John > > On Mar 29, 2009, at 2:02 PM, Charles Oliver Nutter wrote: > >> Charles Oliver Nutter wrote: >>> To get the java.dyn.* classes included in rt.jar, I used Kirill's >>> makefile patch. I've attached a version in "extended git" format >>> which should apply cleanly. >> Forgot the patch... >> >> - Charlie >> diff --git a/make/docs/CORE_PKGS.gmk b/make/docs/CORE_PKGS.gmk > > _______________________________________________ > 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 Fri Apr 3 15:18:28 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Fri, 03 Apr 2009 22:18:28 +0000 Subject: hg: mlvm/mlvm/hotspot: meth, anonk: project files work with ant and/or netbeans Message-ID: <20090403221828.B024FE303@hg.openjdk.java.net> Changeset: 5c5527e09ffe Author: jrose Date: 2009-04-03 15:15 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5c5527e09ffe meth, anonk: project files work with ant and/or netbeans ! anonk.proj.patch ! meth.proj.patch ! series From charles.nutter at sun.com Sun Apr 5 01:10:01 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Sun, 05 Apr 2009 03:10:01 -0500 Subject: Latest instructions on getting and patching In-Reply-To: References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> Message-ID: <49D86759.9020506@sun.com> Ok, here's my status. It turns out that the standard instructions are now basically working, and I'm in the process of modifying JRuby's invokedynamic support for the changes over the past few months. Basically, here's the process for OS X: - follow the instructions in the MLVM repo, with the following modifications: -- clone bsd-port instead of openjdk directly -- remove "testable" from your guards to get invokedynamic support along with method handles (though John says there's still some bugs to fix) -- add "projects" to your guards to also apply John's demo projects for anonymous classes and method handles (and I believe the invokedynamic code in the method handle project is function too, right John?) -- use the *second* set of instructions for applying the patches, with all the raw hg queue commands -- once everything has been applied, follow Stephen Bannasch's instructions for getting it to build as normal -- when running with opcode 186 (new-style invokedynamic) you'll need to turn off verification with -Xverify:none With this process I managed to get JRuby to the point of producing an invokedynamic error (missing bootstrap), which to me is a great success. I hope to have things re-wired in the next day or two and will report back. - Charlie From john.rose at sun.com Mon Apr 6 03:35:00 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Mon, 06 Apr 2009 10:35:00 +0000 Subject: hg: mlvm/mlvm: update build instructions for bsd-port Message-ID: <20090406103500.D7D27E440@hg.openjdk.java.net> Changeset: 41bc9c25b6d0 Author: jrose Date: 2009-04-06 03:30 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/41bc9c25b6d0 update build instructions for bsd-port ! README.txt From john.rose at sun.com Mon Apr 6 03:36:57 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Mon, 06 Apr 2009 10:36:57 +0000 Subject: hg: mlvm/mlvm/hotspot: indy: more demos work Message-ID: <20090406103657.AEA2DE447@hg.openjdk.java.net> Changeset: d88356a6b5e8 Author: jrose Date: 2009-04-06 03:27 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d88356a6b5e8 indy: more demos work ! indy.patch ! indy.txt ! meth.patch ! series From john.rose at sun.com Mon Apr 6 03:38:59 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Mon, 06 Apr 2009 10:38:59 +0000 Subject: hg: mlvm/mlvm/jdk: indy: more demos work Message-ID: <20090406103859.31C32E452@hg.openjdk.java.net> Changeset: 8b5cc1a371e9 Author: jrose Date: 2009-04-06 03:29 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/8b5cc1a371e9 indy: more demos work ! indy.patch + indy.verify.patch ! series From john.rose at sun.com Mon Apr 6 03:40:43 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Mon, 06 Apr 2009 10:40:43 +0000 Subject: hg: mlvm/mlvm/langtools: quid: fix escape-sequence bug Message-ID: <20090406104043.6541BE45B@hg.openjdk.java.net> Changeset: f7eab0ec5cfc Author: jrose Date: 2009-04-06 03:31 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/f7eab0ec5cfc quid: fix escape-sequence bug ! quid.patch From John.Rose at Sun.COM Mon Apr 6 03:48:33 2009 From: John.Rose at Sun.COM (John Rose) Date: Mon, 06 Apr 2009 03:48:33 -0700 Subject: Latest instructions on getting and patching In-Reply-To: <49D86759.9020506@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> Message-ID: <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> On Apr 5, 2009, at 1:10 AM, Charles Oliver Nutter wrote: > - follow the instructions in the MLVM repo, with the following > modifications: > -- clone bsd-port instead of openjdk directly I changed the README to reflect this reality. > -- remove "testable" from your guards to get invokedynamic support > along > with method handles (though John says there's still some bugs to fix) The indy stuff is now marked testable. (Not stable, just testable.) > -- add "projects" to your guards to also apply John's demo projects > for > anonymous classes and method handles (and I believe the invokedynamic > code in the method handle project is function too, right John?) Partially. Some tests pass, some fail. I'm working in it... > -- use the *second* set of instructions for applying the patches, > with > all the raw hg queue commands > -- once everything has been applied, follow Stephen Bannasch's > instructions for getting it to build as normal > -- when running with opcode 186 (new-style invokedynamic) you'll > need to > turn off verification with -Xverify:none I committed a patch to the old plugin-based verifier in the jdk repo, which should fix that. > With this process I managed to get JRuby to the point of producing an > invokedynamic error (missing bootstrap), which to me is a great > success. > I hope to have things re-wired in the next day or two and will > report back. That's great! I think the road is clear for your next step. Upcoming problems are likely to be either something low-level in the new JVM code, or else a missing piece in the java.dyn.MethodHandles API. Thanks for working on this! -- John From john.rose at sun.com Tue Apr 7 01:57:27 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 07 Apr 2009 08:57:27 +0000 Subject: hg: mlvm/mlvm/hotspot: meth: update with round 3 of review Message-ID: <20090407085727.69513E4FC@hg.openjdk.java.net> Changeset: cca273ddf383 Author: jrose Date: 2009-04-07 01:55 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/cca273ddf383 meth: update with round 3 of review + meth-6655638.03.patch ! meth.patch ! series From john.rose at sun.com Tue Apr 7 02:08:40 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Tue, 07 Apr 2009 09:08:40 +0000 Subject: hg: mlvm/mlvm/jdk: meth: update with round 3 of review Message-ID: <20090407090840.4580DE501@hg.openjdk.java.net> Changeset: daca8baee5f4 Author: jrose Date: 2009-04-07 02:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/daca8baee5f4 meth: update with round 3 of review ! meth.patch From john.rose at sun.com Wed Apr 8 02:57:02 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Wed, 08 Apr 2009 09:57:02 +0000 Subject: hg: mlvm/mlvm/hotspot: meth, indy: change impl.java.dyn => sun.dyn; consolidate final 6655638 changes Message-ID: <20090408095702.BF3C9E629@hg.openjdk.java.net> Changeset: fafa7c078a66 Author: jrose Date: 2009-04-08 02:52 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/fafa7c078a66 meth, indy: change impl.java.dyn => sun.dyn; consolidate final 6655638 changes ! indy.patch - meth-6655638.03.patch ! meth-6655638.patch ! meth.patch ! meth.proj.patch ! series From john.rose at sun.com Wed Apr 8 02:59:24 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Wed, 08 Apr 2009 09:59:24 +0000 Subject: hg: mlvm/mlvm/jdk: meth, indy: change impl.java.dyn => sun.dyn; consolidate final 6655638 changes Message-ID: <20090408095925.18CC0E636@hg.openjdk.java.net> Changeset: ebca5d6f234d Author: jrose Date: 2009-04-08 02:53 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ebca5d6f234d meth, indy: change impl.java.dyn => sun.dyn; consolidate final 6655638 changes ! indy.patch ! meth.patch From John.Rose at Sun.COM Thu Apr 9 15:39:13 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 09 Apr 2009 15:39:13 -0700 Subject: Latest instructions on getting and patching In-Reply-To: <49D86759.9020506@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> Message-ID: <5C8EABC7-5919-41C4-BB47-B6D919970F98@sun.com> On Apr 5, 2009, at 1:10 AM, Charles Oliver Nutter wrote: > Ok, here's my status. It turns out that the standard instructions are > now basically working, and I'm in the process of modifying JRuby's > invokedynamic support for the changes over the past few months. Here's a heads-up: The JIT support (minimal to start with) has probably bit-rotted since I changed the format of the instruction. If you get crashes jitting code with indy sites, turn on -Xint on the command line. When you are ready to start pushing performance numbers with indy-- hopefully soon--let me know and I'll make the JIT work for it! -- John From charles.nutter at sun.com Thu Apr 9 15:44:33 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 09 Apr 2009 17:44:33 -0500 Subject: Latest instructions on getting and patching In-Reply-To: <5C8EABC7-5919-41C4-BB47-B6D919970F98@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <5C8EABC7-5919-41C4-BB47-B6D919970F98@sun.com> Message-ID: <49DE7A51.5080002@sun.com> John Rose wrote: > On Apr 5, 2009, at 1:10 AM, Charles Oliver Nutter wrote: > >> Ok, here's my status. It turns out that the standard instructions are >> now basically working, and I'm in the process of modifying JRuby's >> invokedynamic support for the changes over the past few months. > > Here's a heads-up: The JIT support (minimal to start with) has > probably bit-rotted since I changed the format of the instruction. If > you get crashes jitting code with indy sites, turn on -Xint on the > command line. > > When you are ready to start pushing performance numbers with indy-- > hopefully soon--let me know and I'll make the JIT work for it! Ok...I don't have things rewired just yet (AppEngine news has kept us busy this week) but I will get to it soon. Once I have it functioning with -Xint, I'll let you know it's numbers time. - Charlie From John.Rose at Sun.COM Thu Apr 9 16:45:13 2009 From: John.Rose at Sun.COM (John Rose) Date: Thu, 09 Apr 2009 16:45:13 -0700 Subject: Latest instructions on getting and patching In-Reply-To: <49DE7A51.5080002@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <5C8EABC7-5919-41C4-BB47-B6D919970F98@sun.com> <49DE7A51.5080002@sun.com> Message-ID: On Apr 9, 2009, at 3:44 PM, Charles Oliver Nutter wrote: > AppEngine news Cool! More play for a fast JRuby. -- John From benjamin.john.evans at googlemail.com Fri Apr 10 11:23:22 2009 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Fri, 10 Apr 2009 19:23:22 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> Message-ID: <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> Hi John, On Mon, Apr 6, 2009 at 11:48 AM, John Rose wrote: > On Apr 5, 2009, at 1:10 AM, Charles Oliver Nutter wrote: > > > - follow the instructions in the MLVM repo, with the following > > modifications: > > -- clone bsd-port instead of openjdk directly > I changed the README to reflect this reality. > > -- remove "testable" from your guards to get invokedynamic support > > along > > with method handles (though John says there's still some bugs to fix) > The indy stuff is now marked testable. (Not stable, just testable.) I'm having some problems getting the build to complete. Everything seems normal throughout the build - I need to add some additional env variables for the make to work properly, something like: ALT_JDK_IMPORT_PATH=/usr/local/openjdk7-darwin-i386-20090131 ALT_BOOTDIR=/usr/local/openjdk7-darwin-i386-20090131 ALT_BINARY_PLUGS_PATH=/Users/boxcat/jdk-7-icedtea-plugs ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib ALT_CUPS_HEADERS_PATH=/usr/include ANT_HOME=/usr/share/ant NO_DOCS=true HOTSPOT_BUILD_JOBS=1 for my environment (not all of these may be strictly necessary, haven't fully experimented yet). Hotspot, jdk and langtools all seem to build normally, but at the end of the langtools build, I get this: BUILD SUCCESSFUL Total time: 25 seconds gnumake: *** [build] Error 2 and although all the binaries and so forth seem to be built, it doesn't end up with a sources/build/bsd-i586/j2re-image/ directory containing a JRE ready for testing, which is what I was expecting. Still looking in to it, but thought I'd report this - just in case anyone else has been solving similar problems and can put me straight quickly. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090410/5da58154/attachment.html From John.Rose at Sun.COM Fri Apr 10 12:05:14 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 10 Apr 2009 12:05:14 -0700 Subject: Latest instructions on getting and patching In-Reply-To: <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> Message-ID: <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> On Apr 10, 2009, at 11:23 AM, Ben Evans wrote: > ... > BUILD SUCCESSFUL > Total time: 25 seconds > gnumake: *** [build] Error 2 Can you say why gnumake is reporting error status 2? Did ant complain somewhere? When I try an incremental rebuild, the last output looks something like this: > build-all-classes: > > build: > > BUILD SUCCESSFUL > Total time: 8 seconds > Control bsd i586 1.7.0-internal build_product_image build finished: > Control bsd i586 1.7.0-internal all_product_build build finished: > Control bsd i586 1.7.0-internal all build finished: My davinci/sources/build.sh is enclosed, and also posted here, for comparison: http://blogs.sun.com/jrose/resource/davinci-build.sh -- John # source build.sh # This script is originally derived from Stephen Bannasch's instructions: # http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5 # This script is placed in ../davinci/sources/ and run from there. See also: # http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-April/000434.html export LC_ALL=C export LANG=C unset CLASSPATH unset JAVA_HOME #export ALT_BOOTDIR=/usr/local/soylatte16-amd64-1.0.3 sets=' ALT_JDK_IMPORT_PATH=/usr/local/soylatte16-i386-1.0.3 ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 ALT_BINARY_PLUGS_PATH=/Users/jrose/Downloads/JDK7/jdk-7-icedtea-plugs ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib ALT_CUPS_HEADERS_PATH=/usr/include ANT_HOME=/usr/share/ant NO_DOCS=true HOTSPOT_BUILD_JOBS=2 BUILD_LANGTOOLS=true BUILD_JAXP=false BUILD_JAXWS=false BUILD_CORBA=false BUILD_HOTSPOT=true BUILD_JDK=true ' # Execute the above sets, into the environment. for s in $sets; do eval export $s; done # Preview sets in command line for s do case $s in *'[ ;]'*) break;; *'='*) eval "$s";; *) break;; esac done # Incremental JVM rebuilds have trouble with *.gch files. # The *.gch file does not get regenerated unless you remove it, # even if 20 header files have changed. # This is not a problem for batch builds, of course. $BUILD_HOTSPOT && { ${REBUILD_HOTSPOT_HEADERS:-true} || rm -f $(find build -name _precompiled.incl.gch) } # Run make, or whatever, in the resulting environment. eval "${@-make}" # Usage example: For a partial (re-)build of JDK only: # sh build.sh BUILD_{HOTSPOT,LANGTOOLS}=false make -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090410/cf7a8847/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: davinci-build.sh Type: application/octet-stream Size: 1718 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090410/cf7a8847/attachment.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090410/cf7a8847/attachment-0001.html From charles.nutter at sun.com Fri Apr 10 12:10:44 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 10 Apr 2009 14:10:44 -0500 Subject: Latest instructions on getting and patching In-Reply-To: <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> Message-ID: <49DF99B4.3090109@sun.com> We really need some enterprising non-Sun individual to start publishing binaries (hint, hint). John Rose wrote: > On Apr 10, 2009, at 11:23 AM, Ben Evans wrote: > >> ... >> BUILD SUCCESSFUL >> Total time: 25 seconds >> gnumake: *** [build] Error 2 > > Can you say why gnumake is reporting error status 2? Did ant complain > somewhere? When I try an incremental rebuild, the last output looks > something like this: > >> build-all-classes: >> >> build: >> >> BUILD SUCCESSFUL >> Total time: 8 seconds >> Control bsd i586 1.7.0-internal build_product_image build finished: >> Control bsd i586 1.7.0-internal all_product_build build finished: >> Control bsd i586 1.7.0-internal all build finished: > > My davinci/sources/build.sh is enclosed, and also posted here, for > comparison: > http://blogs.sun.com/jrose/resource/davinci-build.sh > > -- John > > # source build.sh > > # This script is originally derived from Stephen Bannasch's > instructions: > # > http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5 > > # This script is placed in ../davinci/sources/ and run from there. > See also: > # > http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-April/000434.html > > export LC_ALL=C > export LANG=C > unset CLASSPATH > unset JAVA_HOME > > #export ALT_BOOTDIR=/usr/local/soylatte16-amd64-1.0.3 > > sets=' > ALT_JDK_IMPORT_PATH=/usr/local/soylatte16-i386-1.0.3 > ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 > ALT_BINARY_PLUGS_PATH=/Users/jrose/Downloads/JDK7/jdk-7-icedtea-plugs > ALT_FREETYPE_HEADERS_PATH=/usr/X11R6/include > ALT_FREETYPE_LIB_PATH=/usr/X11R6/lib > ALT_CUPS_HEADERS_PATH=/usr/include > ANT_HOME=/usr/share/ant > NO_DOCS=true > HOTSPOT_BUILD_JOBS=2 > BUILD_LANGTOOLS=true > BUILD_JAXP=false > BUILD_JAXWS=false > BUILD_CORBA=false > BUILD_HOTSPOT=true > BUILD_JDK=true > ' > # Execute the above sets, into the environment. > for s in $sets; do eval export $s; done > > # Preview sets in command line > for s > do case $s in > *'[ ;]'*) break;; > *'='*) eval "$s";; > *) break;; > esac > done > > # Incremental JVM rebuilds have trouble with *.gch files. > # The *.gch file does not get regenerated unless you remove it, > # even if 20 header files have changed. > # This is not a problem for batch builds, of course. > $BUILD_HOTSPOT && { > ${REBUILD_HOTSPOT_HEADERS:-true} || > rm -f $(find build -name _precompiled.incl.gch) > } > > # Run make, or whatever, in the resulting environment. > eval "${@-make}" > > # Usage example: For a partial (re-)build of JDK only: > # sh build.sh BUILD_{HOTSPOT,LANGTOOLS}=false make > > > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Fri Apr 10 12:14:08 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 10 Apr 2009 12:14:08 -0700 Subject: Latest instructions on getting and patching In-Reply-To: <49DF99B4.3090109@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> Message-ID: <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> On Apr 10, 2009, at 12:10 PM, Charles Oliver Nutter wrote: > We really need some enterprising non-Sun individual to start > publishing > binaries (hint, hint). Indeed. (nudge, nudge) BTW, the main body of method handle support (all meth-NNNN.patch) is now pushed to a sub-integration area (hotspot-comp), and will in due course be part of the OpenJDK snapshot binaries. But this will always be weeks or even months behind any given change in the mlvm patch repository. -- John From charles.nutter at sun.com Fri Apr 10 12:16:09 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 10 Apr 2009 14:16:09 -0500 Subject: Latest instructions on getting and patching In-Reply-To: <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> Message-ID: <49DF9AF9.1070408@sun.com> John Rose wrote: > On Apr 10, 2009, at 12:10 PM, Charles Oliver Nutter wrote: > >> We really need some enterprising non-Sun individual to start >> publishing >> binaries (hint, hint). > > Indeed. (nudge, nudge) > > BTW, the main body of method handle support (all meth-NNNN.patch) is > now pushed to a sub-integration area (hotspot-comp), and will in due > course be part of the OpenJDK snapshot binaries. But this will always > be weeks or even months behind any given change in the mlvm patch > repository. Is there any possibility of the Java-level APIs getting pushed out as a sun.something package? I know we can't shove java.* things without the JSR, but if there were any chance of a hotspot-only meth/indy getting into Java 6 some day it would be a great thing. - Charlie From John.Rose at Sun.COM Fri Apr 10 12:29:09 2009 From: John.Rose at Sun.COM (John Rose) Date: Fri, 10 Apr 2009 12:29:09 -0700 Subject: Latest instructions on getting and patching In-Reply-To: <49DF9AF9.1070408@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <49DF9AF9.1070408@sun.com> Message-ID: <878AB1AB-FA76-4B56-80F9-17E0FFAAFBD2@sun.com> On Apr 10, 2009, at 12:16 PM, Charles Oliver Nutter wrote: > Is there any possibility of the Java-level APIs getting pushed out > as a > sun.something package? I know we can't shove java.* things without the > JSR, but if there were any chance of a hotspot-only meth/indy getting > into Java 6 some day it would be a great thing. Good idea. Perhaps it's possible... We're looking at our JDK options, especially in the lead-up to JavaOne. Since the Hotspot JVM is wired to certain names like java.dyn.MethodHandle, an interim solution that uses only sun.* packages does not look feasible. But it might be practical to remove almost all the JVM linkage from the java.dyn. packages, so they can be separately obtained and applied on the BCP, while the grody infrastructure is distributed with the JVM in the sun.* packages. Also, the JSR EG is not that far away from agreeing on the APIs. It's just that there are lots small details to worry about. -- John From charles.nutter at sun.com Fri Apr 10 12:38:17 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 10 Apr 2009 14:38:17 -0500 Subject: Latest instructions on getting and patching In-Reply-To: <878AB1AB-FA76-4B56-80F9-17E0FFAAFBD2@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <49DF9AF9.1070408@sun.com> <878AB1AB-FA76-4B56-80F9-17E0FFAAFBD2@sun.com> Message-ID: <49DFA029.6090503@sun.com> John Rose wrote: > Good idea. Perhaps it's possible... We're looking at our JDK options, > especially in the lead-up to JavaOne. > > Since the Hotspot JVM is wired to certain names like > java.dyn.MethodHandle, an interim solution that uses only sun.* > packages does not look feasible. > > But it might be practical to remove almost all the JVM linkage from > the java.dyn. packages, so they can be separately obtained and applied > on the BCP, while the grody infrastructure is distributed with the JVM > in the sun.* packages. > > Also, the JSR EG is not that far away from agreeing on the APIs. It's > just that there are lots small details to worry about. If there's anything I can do to help make the case for certain JSR features/questions/concerns, let me know. I can certainly write something up that Ola or you can deliver to the WG. - Charlie From forax at univ-mlv.fr Sat Apr 11 07:33:41 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 11 Apr 2009 16:33:41 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <878AB1AB-FA76-4B56-80F9-17E0FFAAFBD2@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <49DF9AF9.1070408@sun.com> <878AB1AB-FA76-4B56-80F9-17E0FFAAFBD2@sun.com> Message-ID: <49E0AA45.3030906@univ-mlv.fr> John Rose a ?crit : ... > Also, the JSR EG is not that far away from agreeing on the APIs. It's > just that there are lots small details to worry about. > Last week, I've noted that one of the factory method in MethodType is not correctly generified: MethodType.make(Class rtype, List> ptypes) should be MethodType.make(Class rtype, List> ptypes) Even if java.lang.Class is final, final is not used by the Java type system. > -- John > R?mi From John.Rose at Sun.COM Sat Apr 11 13:39:04 2009 From: John.Rose at Sun.COM (John Rose) Date: Sat, 11 Apr 2009 13:39:04 -0700 Subject: Latest instructions on getting and patching In-Reply-To: <49E0AA45.3030906@univ-mlv.fr> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <49DF9AF9.1070408@sun.com> <878AB1AB-FA76-4B56-80F9-17E0FFAAFBD2@sun.com> <49E0AA45.3030906@univ-mlv.fr> Message-ID: <07CB95FD-14EF-47C1-8B73-88B65A78ED2E@sun.com> On Apr 11, 2009, at 7:33 AM, R?mi Forax wrote: > MethodType.make(Class rtype, List> ptypes) > > Even if java.lang.Class is final, final is not used by the Java type > system. Thanks! I fixed it. FYI, I pushed a raw snapshot of all the currently proposed JDK changes here: http://cr.openjdk.java.net/~jrose/6829144/webrev.00/ -- John From benjamin.john.evans at googlemail.com Sun Apr 12 05:06:06 2009 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Sun, 12 Apr 2009 13:06:06 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> Message-ID: <38a53eb30904120506g1822ea91n2883871b188fb415@mail.gmail.com> 2009/4/10 John Rose > On Apr 10, 2009, at 11:23 AM, Ben Evans wrote: > > ... > > BUILD SUCCESSFUL > Total time: 25 seconds > gnumake: *** [build] Error 2 > > > Can you say why gnumake is reporting error status 2? Did ant complain > somewhere? When I try an incremental rebuild, the last output looks > something like this: > Digging into this, it looks like the failure occurs much earlier - but that it fails to terminate the build. I think the culprit is this section: cd bsd_i486_compiler2/product && ./test_gamma openjdk full version "1.7.0-internal-boxcat_2009_02_01_14_00-b00" Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object gnumake[3]: *** [product] Error 1 gnumake[2]: *** [generic_build2] Error 2 gnumake[1]: *** [product] Error 2 *** Exit status 2. > build-all-classes: > > build: > > BUILD SUCCESSFUL > Total time: 8 seconds > Control bsd i586 1.7.0-internal build_product_image build finished: > Control bsd i586 1.7.0-internal all_product_build build finished: > Control bsd i586 1.7.0-internal all build finished: > > > My davinci/sources/build.sh is enclosed, and also posted here, for > comparison: > http://blogs.sun.com/jrose/resource/davinci-build.sh > Thanks. I'm pretty confident that this is something environmental to my build - will try and track down and report. Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090412/76d98929/attachment.html From scheme.mlvm at gmail.com Sun Apr 12 17:11:21 2009 From: scheme.mlvm at gmail.com (scheme.mlvm) Date: Mon, 13 Apr 2009 02:11:21 +0200 Subject: makeSite_signature still has impl/java/dyn return type, hotspot indy.patch Message-ID: <8F95DB45670B484FA070946DC3C85393@jhtm432lc> Hi! I'm quite new to mlvm. Tried to run InvokeDynamicDemo linked at http://blogs.sun.com/jrose/entry/simple_java_linkage_with_invokedynamic Finally succeeded with compilation, but execution failed with: Exception in thread "main" java.lang.NoSuchMethodError: sun.dyn.CallSiteImpl.makeSite(Ljava/lang/Class;Ljava/lang/String;Ljava/dyn/MethodType;II)Limpl/java/dyn/CallSiteImpl; at GetNameDemo.main(GetNameDemo.java:40) at Main.main(Main.java:34) Traced it to patches/hotspot/indy.patch, where impl/java/dyn is still used instead of recently introduced sun.dyn: + template(makeSite_signature, "(Ljava/lang/Class;Ljava/lang/String;Ljava/dyn/MethodType;II)Limpl/java/dyn/CallSiteImpl;") \ Not sure about effects in patches/jdk/meth.patch: +AUTO_FILES_JAVA_DIRS = java/dyn impl/java/dyn impl/java/dyn/util Still a bit lost in mecurial forest, but I believe my repos to be up-to-date: (cd patches/hotspot; hg pull; hg update; hg identify) pulling from http://hg.openjdk.java.net/mlvm/mlvm/hotspot searching for changes no changes found 0 files updated, 0 files merged, 0 files removed, 0 files unresolved fafa7c078a66 tip fyi, juergen From benjamin.john.evans at googlemail.com Mon Apr 13 09:40:05 2009 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Mon, 13 Apr 2009 17:40:05 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <38a53eb30904120506g1822ea91n2883871b188fb415@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <38a53eb30904120506g1822ea91n2883871b188fb415@mail.gmail.com> Message-ID: <38a53eb30904130940v2358a1c3p5a0686a879bccb8c@mail.gmail.com> On Sun, Apr 12, 2009 at 1:06 PM, Ben Evans < benjamin.john.evans at googlemail.com> wrote: > 2009/4/10 John Rose > >> On Apr 10, 2009, at 11:23 AM, Ben Evans wrote: >> >> ... >> >> BUILD SUCCESSFUL >> Total time: 25 seconds >> gnumake: *** [build] Error 2 >> >> >> Can you say why gnumake is reporting error status 2? Did ant complain >> somewhere? When I try an incremental rebuild, the last output looks >> something like this: >> > > Digging into this, it looks like the failure occurs much earlier - but that > it fails to terminate the build. > > I think the culprit is this section: > > cd bsd_i486_compiler2/product && ./test_gamma > openjdk full version "1.7.0-internal-boxcat_2009_02_01_14_00-b00" > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: java/lang/Object > gnumake[3]: *** [product] Error 1 > gnumake[2]: *** [generic_build2] Error 2 > gnumake[1]: *** [product] Error 2 > *** Exit status 2. > > I'm pretty confident that this is something environmental to my build - > will try and track down and report. After trying several other builds, I can get a clean build providing I start with SoyLatte. However, if I try to use any OpenJDK7 build (including Langdon's binaries from last Summer), no good. It always seems to fail over the Queens.java test. It doesn't always fail with the same message, and the OpenJDK7 builds (including some I made myself) have otherwise worked fine - they're my standard JRE for all of my Eclipse sessions at home, for example, and I haven't had a single failure from them. Has anyone else tried to used an OpenJDK7 environment to build MLVM, rather than SoyLatte? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090413/5ae50618/attachment.html From charles.nutter at sun.com Mon Apr 13 11:07:47 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Mon, 13 Apr 2009 13:07:47 -0500 Subject: Latest instructions on getting and patching In-Reply-To: <38a53eb30904130940v2358a1c3p5a0686a879bccb8c@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <38a53eb30904120506g1822ea91n2883871b188fb415@mail.gmail.com> <38a53eb30904130940v2358a1c3p5a0686a879bccb8c@mail.gmail.com> Message-ID: <49E37F73.9010701@sun.com> Ben Evans wrote: > After trying several other builds, I can get a clean build providing I > start with SoyLatte. > > However, if I try to use any OpenJDK7 build (including Langdon's > binaries from last Summer), no good. It always seems to fail over the > Queens.java test. It doesn't always fail with the same message, and the > OpenJDK7 builds (including some I made myself) have otherwise worked > fine - they're my standard JRE for all of my Eclipse sessions at home, > for example, and I haven't had a single failure from them. > > Has anyone else tried to used an OpenJDK7 environment to build MLVM, > rather than SoyLatte? No, but I did see the Queens.java error come up once and didn't know why. That could be it. I wonder what the problem is? Every time I've gotten a good build, I have always built with SoyLatte. - Charlie From szegedia at gmail.com Sun Apr 19 05:55:20 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 19 Apr 2009 14:55:20 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <49CE92FC.3010902@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> Message-ID: <43FC5CDA-3858-4B80-8668-C51EB4EE5E8D@gmail.com> Hi folks, I'm on the bandwagon too now, trying to build the MLVM (so I can start on the invokedynamic/method handles based MOP). Here's some additions, plus where I got stuck: On 2009.03.28., at 22:13, Charles Oliver Nutter wrote: > > Ok, another attempt. John Rose has rebased the patches for bsd-port, > and > I've got a build running. The above instructions are ok, except that > RELAX_CHECKS=true was necessary for the make portion. So my modified > sequence: > > 1. get a buildable bsd-port by following Stephen Bannasch's > instructions > here: > http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5 1.a add hgext.mq= to [extensions] in ~/.hgrc > 2. somewhere else, mkdir davinci > 3. cd davinci > 4. ln -s ../bsd-port sources Makes it fairly fixed where's that "somewhere else" for davinci in step 2, doesn't it ;-) ? > 5. hg fclone http://hg.openjdk.java.net/mlvm/mlvm patches Did that, actually fpull/fupdate since I had an older bsd-port, but that's beside the point. 5.a. applied Charlie's patches from a followup e-mail to Makefiles to include java.dyn in rt.jar > 6. (cd patches/make; gnumake setup) > 7. export RELAX_CHECKS=true > 8. (cd patches/make; gnumake) Gives the following output, error message at the bottom: cd ../..; bash patches/make/link-patch-dirs.sh sources patches + ln -s /Users/aszegedi/Documents/projects/openjdk/davinci/patches/ hotspot /Users/aszegedi/Documents/projects/openjdk/bsd-port/ hotspot/.hg/patches + ln -s /Users/aszegedi/Documents/projects/openjdk/davinci/patches/ jdk /Users/aszegedi/Documents/projects/openjdk/bsd-port/jdk/.hg/patches + ln -s /Users/aszegedi/Documents/projects/openjdk/davinci/patches/ langtools /Users/aszegedi/Documents/projects/openjdk/bsd-port/ langtools/.hg/patches # Should be identical files: cd ../..; ls -il patches/hotspot/series sources/hotspot/.hg/patches/ series 4688074 -rw-r--r-- 1 aszegedi aszegedi 1024 ?pr 19 13:59 patches/ hotspot/series 4688074 -rw-r--r-- 1 aszegedi aszegedi 1024 ?pr 19 13:59 sources/ hotspot/.hg/patches/series cd ../..; ksh patches/make/each-patch-repo.sh \ "hg qpop -a; hg qselect buildable testable" \ "\$(ksh `pwd`/patches/make/current-release.sh)" + (cd sources/hotspot; hg qpop -a; hg qselect buildable testable $ (ksh /Users/aszegedi/Documents/projects/openjdk/davinci/patches/make/ current-release.sh)) no patches applied + (cd sources/jdk; hg qpop -a; hg qselect buildable testable $(ksh / Users/aszegedi/Documents/projects/openjdk/davinci/patches/make/current- release.sh)) no patches applied + (cd sources/langtools; hg qpop -a; hg qselect buildable testable $ (ksh /Users/aszegedi/Documents/projects/openjdk/davinci/patches/make/ current-release.sh)) no patches applied # report what happened: cd ../..; ksh patches/make/each-patch-repo.sh 'hg qselect; hg qunapplied' + (cd sources/hotspot; hg qselect; hg qunapplied) 05f8c84c5daa buildable testable meth-asm-6812678.patch meth-ilookup-6812831.patch meth-subtype-6813212.patch meth-minor-6814659.patch meth-6655638.patch meth.patch indy.patch + (cd sources/jdk; hg qselect; hg qunapplied) 940223097cb1 buildable testable anonk.patch meth.patch indy.patch indy.verify.patch + (cd sources/langtools; hg qselect; hg qunapplied) 80586310cc78 buildable testable quid.patch meth.patch dyncast.patch cd ../..; ksh patches/make/each-patch-repo.sh \ '(! hg qunapplied | read something) || hg qpush -a' + (cd sources/hotspot; (! hg qunapplied | read something) || hg qpush - a) applying meth-asm-6812678.patch applying meth-ilookup-6812831.patch applying meth-subtype-6813212.patch applying meth-minor-6814659.patch applying meth-6655638.patch applying meth.patch applying indy.patch skipping annot.patch - guarded by '-testable' skipping inti.patch - guarded by '-buildable' skipping callcc.patch - guarded by '-testable' skipping tailc.patch - guarded by '-testable' skipping meth.proj.patch - guarded by ['+projects'] skipping anonk.proj.patch - guarded by ['+projects'] now at: indy.patch + (cd sources/jdk; (! hg qunapplied | read something) || hg qpush -a) abort: local changes found, refresh first *** Exit status 255. + (cd sources/langtools; (! hg qunapplied | read something) || hg qpush -a) applying quid.patch applying meth.patch applying dyncast.patch now at: dyncast.patch gnumake: *** [mq-push-patches] Error 255 Other than applying Charlie's patches to makefiles, the bsd-port sources are clean (well, I sure didn't modify any of them manually). As I said, I used fpull/fupdate instead of fclone as I already had bsd- port fcloned... Any idea what's wrong and how can I resolve it? Thanks, Attila. > > It's building now. I believe this sequence only applies the "testable" > items, which includes only method handles right now. > > I'll report back shortly. > > - Charlie From szegedia at gmail.com Sun Apr 19 06:38:39 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 19 Apr 2009 15:38:39 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <43FC5CDA-3858-4B80-8668-C51EB4EE5E8D@gmail.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <43FC5CDA-3858-4B80-8668-C51EB4EE5E8D@gmail.com> Message-ID: Ah, okay, Charlie's patches should no longer be applied -- they're now part of the patchset. I reverted them and the indy patch now applies. I seem to be on a good way to have MLVM built on Mac OS X :-) (Famous last words, eh?) Attila. On 2009.04.19., at 14:55, Attila Szegedi wrote: > Hi folks, > > I'm on the bandwagon too now, trying to build the MLVM (so I can > start on the invokedynamic/method handles based MOP). Here's some > additions, plus where I got stuck: > > On 2009.03.28., at 22:13, Charles Oliver Nutter wrote: > >> >> Ok, another attempt. John Rose has rebased the patches for bsd- >> port, and >> I've got a build running. The above instructions are ok, except that >> RELAX_CHECKS=true was necessary for the make portion. So my modified >> sequence: >> >> 1. get a buildable bsd-port by following Stephen Bannasch's >> instructions >> here: >> http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5 > > 1.a add hgext.mq= to [extensions] in ~/.hgrc > >> 2. somewhere else, mkdir davinci >> 3. cd davinci >> 4. ln -s ../bsd-port sources > > Makes it fairly fixed where's that "somewhere else" for davinci in > step 2, doesn't it ;-) ? > >> 5. hg fclone http://hg.openjdk.java.net/mlvm/mlvm patches > > Did that, actually fpull/fupdate since I had an older bsd-port, but > that's beside the point. > > 5.a. applied Charlie's patches from a followup e-mail to Makefiles > to include java.dyn in rt.jar > >> 6. (cd patches/make; gnumake setup) >> 7. export RELAX_CHECKS=true >> 8. (cd patches/make; gnumake) > > Gives the following output, error message at the bottom: > > cd ../..; bash patches/make/link-patch-dirs.sh sources patches > + ln -s /Users/aszegedi/Documents/projects/openjdk/davinci/patches/ > hotspot /Users/aszegedi/Documents/projects/openjdk/bsd-port/ > hotspot/.hg/patches > + ln -s /Users/aszegedi/Documents/projects/openjdk/davinci/patches/ > jdk /Users/aszegedi/Documents/projects/openjdk/bsd-port/jdk/.hg/ > patches > + ln -s /Users/aszegedi/Documents/projects/openjdk/davinci/patches/ > langtools /Users/aszegedi/Documents/projects/openjdk/bsd-port/ > langtools/.hg/patches > # Should be identical files: > cd ../..; ls -il patches/hotspot/series sources/hotspot/.hg/patches/ > series > 4688074 -rw-r--r-- 1 aszegedi aszegedi 1024 ?pr 19 13:59 patches/ > hotspot/series > 4688074 -rw-r--r-- 1 aszegedi aszegedi 1024 ?pr 19 13:59 sources/ > hotspot/.hg/patches/series > cd ../..; ksh patches/make/each-patch-repo.sh \ > "hg qpop -a; hg qselect buildable testable" \ > "\$(ksh `pwd`/patches/make/current-release.sh)" > + (cd sources/hotspot; hg qpop -a; hg qselect buildable testable $ > (ksh /Users/aszegedi/Documents/projects/openjdk/davinci/patches/ > make/current-release.sh)) > no patches applied > + (cd sources/jdk; hg qpop -a; hg qselect buildable testable $ > (ksh /Users/aszegedi/Documents/projects/openjdk/davinci/patches/ > make/current-release.sh)) > no patches applied > + (cd sources/langtools; hg qpop -a; hg qselect buildable testable $ > (ksh /Users/aszegedi/Documents/projects/openjdk/davinci/patches/ > make/current-release.sh)) > no patches applied > # report what happened: > cd ../..; ksh patches/make/each-patch-repo.sh 'hg qselect; hg > qunapplied' > + (cd sources/hotspot; hg qselect; hg qunapplied) > 05f8c84c5daa > buildable > testable > meth-asm-6812678.patch > meth-ilookup-6812831.patch > meth-subtype-6813212.patch > meth-minor-6814659.patch > meth-6655638.patch > meth.patch > indy.patch > + (cd sources/jdk; hg qselect; hg qunapplied) > 940223097cb1 > buildable > testable > anonk.patch > meth.patch > indy.patch > indy.verify.patch > + (cd sources/langtools; hg qselect; hg qunapplied) > 80586310cc78 > buildable > testable > quid.patch > meth.patch > dyncast.patch > cd ../..; ksh patches/make/each-patch-repo.sh \ > '(! hg qunapplied | read something) || hg qpush -a' > + (cd sources/hotspot; (! hg qunapplied | read something) || hg > qpush -a) > applying meth-asm-6812678.patch > applying meth-ilookup-6812831.patch > applying meth-subtype-6813212.patch > applying meth-minor-6814659.patch > applying meth-6655638.patch > applying meth.patch > applying indy.patch > skipping annot.patch - guarded by '-testable' > skipping inti.patch - guarded by '-buildable' > skipping callcc.patch - guarded by '-testable' > skipping tailc.patch - guarded by '-testable' > skipping meth.proj.patch - guarded by ['+projects'] > skipping anonk.proj.patch - guarded by ['+projects'] > now at: indy.patch > + (cd sources/jdk; (! hg qunapplied | read something) || hg qpush -a) > abort: local changes found, refresh first > *** Exit status 255. > + (cd sources/langtools; (! hg qunapplied | read something) || hg > qpush -a) > applying quid.patch > applying meth.patch > applying dyncast.patch > now at: dyncast.patch > gnumake: *** [mq-push-patches] Error 255 > > Other than applying Charlie's patches to makefiles, the bsd-port > sources are clean (well, I sure didn't modify any of them manually). > As I said, I used fpull/fupdate instead of fclone as I already had > bsd-port fcloned... Any idea what's wrong and how can I resolve it? > > Thanks, > Attila. > >> >> It's building now. I believe this sequence only applies the >> "testable" >> items, which includes only method handles right now. >> >> I'll report back shortly. >> >> - Charlie From benjamin.john.evans at googlemail.com Sun Apr 19 08:47:26 2009 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Sun, 19 Apr 2009 16:47:26 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <49E37F73.9010701@sun.com> References: <49BD4FD6.4080306@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <38a53eb30904120506g1822ea91n2883871b188fb415@mail.gmail.com> <38a53eb30904130940v2358a1c3p5a0686a879bccb8c@mail.gmail.com> <49E37F73.9010701@sun.com> Message-ID: <38a53eb30904190847l1120aee2hbafe191282dc684c@mail.gmail.com> On Mon, Apr 13, 2009 at 7:07 PM, Charles Oliver Nutter < charles.nutter at sun.com> wrote: > Ben Evans wrote: > > After trying several other builds, I can get a clean build providing I > > start with SoyLatte. > > > > However, if I try to use any OpenJDK7 build (including Langdon's > > binaries from last Summer), no good. It always seems to fail over the > > Queens.java test. It doesn't always fail with the same message, and the > > OpenJDK7 builds (including some I made myself) have otherwise worked > > fine - they're my standard JRE for all of my Eclipse sessions at home, > > for example, and I haven't had a single failure from them. > > > > Has anyone else tried to used an OpenJDK7 environment to build MLVM, > > rather than SoyLatte? > > No, but I did see the Queens.java error come up once and didn't know > why. That could be it. I wonder what the problem is? > > Every time I've gotten a good build, I have always built with SoyLatte. > Just to add my status to this thread, I've now got a solid build using SoyLatte, and have got Remi's examples (from http://weblogs.java.net/blog/forax/archive/2009/01/method_handles.html) up and running in my environment (including inside Eclipse). I've written up my efforts here: http://boxcatjunction.blogspot.com/2009/04/invokedynamic-on-os-x-update.html- but it's mostly just a collation of the various sources I've used for my build. I've also been talking with some people from the Perl world about helping with my toy Perl-like language (which will need to use invokedynamic heavily, if I'm understanding the use case right). I'll put out a blog post with the state of play on that project soon. Still no dice with using OpenJDK7 to build mlvm - if anyone does manage to get it to build on OS X, could they let me / the list know? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090419/cbb3f37c/attachment.html From szegedia at gmail.com Sun Apr 19 09:11:03 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 19 Apr 2009 18:11:03 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> Message-ID: <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> I successfully built mlvm for Intel Mac OS X from today's Mercurial sources, and I can publish the binaries. Am I right that I basically need to create a tarball of build/bsd-i586/j2sdk-image directory? Also, what am I allowed to call this thing? Attila. On 2009.04.10., at 21:14, John Rose wrote: > On Apr 10, 2009, at 12:10 PM, Charles Oliver Nutter wrote: > >> We really need some enterprising non-Sun individual to start >> publishing >> binaries (hint, hint). > > Indeed. (nudge, nudge) > > BTW, the main body of method handle support (all meth-NNNN.patch) is > now pushed to a sub-integration area (hotspot-comp), and will in due > course be part of the OpenJDK snapshot binaries. But this will always > be weeks or even months behind any given change in the mlvm patch > repository. > > -- John From szegedia at gmail.com Sun Apr 19 09:12:08 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 19 Apr 2009 18:12:08 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <38a53eb30904190847l1120aee2hbafe191282dc684c@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <38a53eb30904120506g1822ea91n2883871b188fb415@mail.gmail.com> <38a53eb30904130940v2358a1c3p5a0686a879bccb8c@mail.gmail.com> <49E37F73.9010701@sun.com> <38a53eb30904190847l1120aee2hbafe191282dc684c@mail.gmail.com> Message-ID: <4D004E94-0F5D-4633-AC5B-5578B1C28C46@gmail.com> I also built it using SoyLatte for bootstrap. What would be the benefit (if any) of using OpenJDK7 to build it? Attila. On 2009.04.19., at 17:47, Ben Evans wrote: > Still no dice with using OpenJDK7 to build mlvm - if anyone does > manage to get it to build on OS X, could they let me / the list know? > > Thanks, > > Ben From charles.nutter at sun.com Sun Apr 19 11:28:37 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Sun, 19 Apr 2009 13:28:37 -0500 Subject: Latest instructions on getting and patching In-Reply-To: <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> References: <49BD4FD6.4080306@sun.com> <49BD50A8.9040609@sun.com> <49CE92FC.3010902@sun.com> <49CFAAAE.1020804@sun.com> <49CFE1DB.8020507@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> Message-ID: <49EB6D55.8070108@sun.com> I suppose that's a good question, for which I don't have an answer :) But I look forward to having published binaries. I'll ask around. Attila Szegedi wrote: > I successfully built mlvm for Intel Mac OS X from today's Mercurial > sources, and I can publish the binaries. Am I right that I basically > need to create a tarball of build/bsd-i586/j2sdk-image directory? > Also, what am I allowed to call this thing? > > Attila. > > On 2009.04.10., at 21:14, John Rose wrote: > >> On Apr 10, 2009, at 12:10 PM, Charles Oliver Nutter wrote: >> >>> We really need some enterprising non-Sun individual to start >>> publishing >>> binaries (hint, hint). >> Indeed. (nudge, nudge) >> >> BTW, the main body of method handle support (all meth-NNNN.patch) is >> now pushed to a sub-integration area (hotspot-comp), and will in due >> course be part of the OpenJDK snapshot binaries. But this will always >> be weeks or even months behind any given change in the mlvm patch >> repository. >> >> -- John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev From benjamin.john.evans at googlemail.com Sun Apr 19 11:41:17 2009 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Sun, 19 Apr 2009 19:41:17 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <49EB6D55.8070108@sun.com> References: <49BD4FD6.4080306@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> <49EB6D55.8070108@sun.com> Message-ID: <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> On Sun, Apr 19, 2009 at 7:28 PM, Charles Oliver Nutter < charles.nutter at sun.com> wrote: > I suppose that's a good question, for which I don't have an answer :) > But I look forward to having published binaries. I'll ask around. I just call 'em OpenJDK7 binaries. Now that several of us seem to be able to build pretty reliably, should we start looking for a build farm somewhere where we can do automated nightly builds? Such things must, surely, exist to support open projects like this one? Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090419/4314ffd8/attachment.html From szegedia at gmail.com Sun Apr 19 12:40:11 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Sun, 19 Apr 2009 21:40:11 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <49D86759.9020506@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> <49EB6D55.8070108@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> Message-ID: Okay, in the end, I didn't really name it, I just use "mlvm" So, an binary build of MLVM for Mac OS X 10.5.x on Intel processors is now available here: When you unpack it, it will create a directory named "j2sdk_image". Use at your own risk :-) Seriously, I barely had time to try whether it works at all, but if I accidentally bungled anything, I'll build and publish a new version and post an update message here. Attila. On 2009.04.19., at 20:41, Ben Evans wrote: > On Sun, Apr 19, 2009 at 7:28 PM, Charles Oliver Nutter > wrote: > I suppose that's a good question, for which I don't have an answer :) > But I look forward to having published binaries. I'll ask around. > > I just call 'em OpenJDK7 binaries. > > Now that several of us seem to be able to build pretty reliably, > should we start looking for a build farm somewhere where we can do > automated nightly builds? Such things must, surely, exist to support > open projects like this one? > > Ben From thobes at gmail.com Mon Apr 20 03:31:11 2009 From: thobes at gmail.com (Tobias Ivarsson) Date: Mon, 20 Apr 2009 12:31:11 +0200 Subject: Latest instructions on getting and patching In-Reply-To: References: <49BD4FD6.4080306@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> <49EB6D55.8070108@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> Message-ID: <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> Just thought I'd download the binaries and see if they worked on Mac OS 10.4: ~/Desktop/j2sdk-image tobias$ ./bin/java -version Bus error So I guess I'll stick with Linux, hope that the current focus on being able to build the MLVM on Mac doesn't make it unbuildable on Linux systems. /Tobias On Sun, Apr 19, 2009 at 9:40 PM, Attila Szegedi wrote: > Okay, in the end, I didn't really name it, I just use "mlvm" > > So, an binary build of MLVM for Mac OS X 10.5.x on Intel processors is > now available here: > > > > When you unpack it, it will create a directory named "j2sdk_image". > Use at your own risk :-) Seriously, I barely had time to try whether > it works at all, but if I accidentally bungled anything, I'll build > and publish a new version and post an update message here. > > Attila. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090420/f70b8344/attachment.html From forax at univ-mlv.fr Mon Apr 20 03:51:58 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 20 Apr 2009 12:51:58 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <76249B8F-EE35-4901-83B8-E6C18C20101A@sun.com> <38a53eb30904101123l2bcea14dkc77fa53bf63afed1@mail.gmail.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> <49EB6D55.8070108@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> Message-ID: <49EC53CE.8010807@univ-mlv.fr> Tobias Ivarsson a ?crit : > Just thought I'd download the binaries and see if they worked on Mac > OS 10.4: > > ~/Desktop/j2sdk-image tobias$ ./bin/java -version > Bus error > > So I guess I'll stick with Linux, hope that the current focus on being > able to build the MLVM on Mac doesn't make it unbuildable on Linux > systems. Currently, it's buildable on my fedora 10 :) > > /Tobias R?mi > > On Sun, Apr 19, 2009 at 9:40 PM, Attila Szegedi > wrote: > > Okay, in the end, I didn't really name it, I just use "mlvm" > > So, an binary build of MLVM for Mac OS X 10.5.x on Intel processors is > now available here: > > > > When you unpack it, it will create a directory named "j2sdk_image". > Use at your own risk :-) Seriously, I barely had time to try whether > it works at all, but if I accidentally bungled anything, I'll build > and publish a new version and post an update message here. > > Attila. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Apr 21 17:03:06 2009 From: John.Rose at Sun.COM (John Rose) Date: Tue, 21 Apr 2009 17:03:06 -0700 Subject: Ask for a patch review: CallSite.target is not volatile References: <48D2E6F2.404@univ-mlv.fr> Message-ID: <37655E35-26E4-482C-A542-A69426B02D38@sun.com> I'm gathering up issues from old mail, and found the incomplete exchange below on the mlvm dev list. I've followed your advice and removed the "protected" keyword from CallSite fields. The accessors are sufficient. I'm also going to remove the single-inheritance mixin pattern which you objected to, since IBM has also objected to it (on the EG). Basically, I'm going to have the JVM special-case MethodHandle instead of a superclass sun.dyn.MethodHandleImpl. (My English teacher in high school used to say, "kill your darlings", meaning that, if you have a bit of writing you think particularly clever, you probably need to edit it.) I've raised the issues about target invalidation with the EG. Are there other issues in the exchange below that we should call out? Thanks, -- John Begin forwarded message: From: R?mi Forax Date: September 18, 2008 4:40:34 PM PDT To: Da Vinci Machine Project Subject: Re: Ask for a patch review: CallSite.target is not volatile Reply-To: Da Vinci Machine Project John Rose a ?crit : > On Sep 13, 2008, at 7:27 AM, R?mi Forax wrote: > > >> currently CallSite.target is not volatile, so if an invokedynamic >> bootstrap >> method calls setTarget() in one thread, other threads may not see the >> new target. >> >> Proposed changes : >> - make target volatile >> - use unsafe.putOrdered to set the field in a more lightweight way. >> > > Hmm... The EDR is ambiguous about this, and needs to be tightened > up. It does say that the bulk invalidation API is intended to > provide a global interlock, and gives some freedom to the propagation > of setTarget effects. What the EDR says about "next call" refers to > a global ordering that doesn't really exist in the JVM apart from > synchronization. > yop, i have seen that. I'm currently not able to provide that requirement for the backport. > Native JVM implementations don't require target to be explicitly > volatile. In fact, individual threads need the freedom to cache the > target, e.g., as a loop invariant for a fast-path version of a loop. > The important thing to optimize here is the speed of *reading* the > target field. Writes can be as slow as we want (I use a native > method call). > The problem is if a new class is loaded by another thread, I may want to change the target for any other threads. If you cache the target, it will not change when a new class is discovered. i.e the target will change in RAM but not in the local cache. ConcurrentLinkedQueue queue=... thread1: for(Data data:queue) { // invokedynamic call using data } thread2: queue.add(new DataSubClass()); // here the classloader load DataSubClass and // defeat the optimisation done at // invokedynamic call site. > All this is independent of whether the code says "volatile" or not on > the field, but it may be better not to mark it volatile, since that > seems to make a guarantee about propagation of setTarget effects. > > Note that the JVM reads the target field in a specialized way, not > necessarily through a bytecode. Also, the writes to the target field > go through an accessor, so once again, the volatility of the field > does not necessarily matter. not agree, if the accessor is inlined, target can be not reloaded from the RAM. > Except to the backport. For the > backport, I guess the volatile bit is needed. So, yes, that's a good > change. > Yes. > Maybe the right thing to do is move target into a mixin-style > superclass, java.dyn.impl.CS, and have it be volatile in the backport. > I'am not sure you can avoid the volatile read. > This takes me to the second proposed change. > > >> - change alls field visibility from protected to private because : >> 1) protected fields appear in the JavaDoc, >> so another implementation of CallSite (like the one currently >> use by the backport) >> is not allowed. >> 2) caller, name and type are final so caller(), name() and type() >> can be used instead. >> subclasses can override checkTarget() to do nothing, in that >> case setTarget() is equivalent to change the target field. >> So I see no reason to declare this fields protected. >> > > I want the CallSite to be usable two ways: > 1. created by the JVM to reify invokedynamic instructions > 2. creatable by Java code to simulate invokedynamic sites > interpretively > > Therefore, it's important to allow Java code to make its own flavor > of CallSite. Hence the protected methods & fields. > > This could also be done with a CallSite interface, but it seems > easier to me (and to other JVM vendors I think) to make it a concrete > class. > > Therefore, let's keep the protected stuff for now, unless we decide > to make CallSite into an interface. > You don't need protected field if you have accessors. And currently those accessors exist. > I want to factor the 292 API into common classes, including the > public ones, and non-standard implementation-specific classes, one > version for each kind of JVM and one for the backport. The > java.dyn.impl package contains the implementation-specific classes. > (This name will change to go outside of the java.* hierarchy.) When > a public type needs to mix in fields or methods, it does so via > inheritance from an implementation superclass. Switching between > backport and native implementations will therefore require > adjustments to boot class path or the installed rt.jar. > Why not use a static final field, like the anonk code already does ? and detect at runtime if there is a native impl or if the backport must be used. > Why use mixins? Although such pluggable implementations are more > often done via delegation or subclassing, the performance > requirements of method handles requires a more aggressive (less > flexible) pattern of single-inheritance mixins. > I think a static final field is a better option. > -- John > R?mi _______________________________________________ mlvm-dev mailing list mlvm-dev at openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev Begin forwarded message: From: John Rose Date: September 18, 2008 5:40:06 PM PDT To: Da Vinci Machine Project Subject: Re: Ask for a patch review: CallSite.target is not volatile Reply-To: Da Vinci Machine Project On Sep 18, 2008, at 4:40 PM, R?mi Forax wrote: > The problem is if a new class is loaded by another thread, > I may want to change the target for any other threads. > If you cache the target, it will not change when a new class is > discovered. > i.e the target will change in RAM but not in the local cache. Do we agree that an cached old target is not a correctness issue? A system which an have out-of-date targets that has to be robust against such changes even without a volatile variable. The target method itself must include whatever version checks are needed for correctness. What volatile might buy you is a slightly better guarantee that the new target will be seen earlier. But, if the old target has a correctness check, it will presumably have a slow path to clean up when a problem is seen, and this in turn, if it changes the state of memory, will cause the thread to reload even a non-volatile target field. If a language system use targets that do not perform version checks (against data structures with variable semantics, such as open inheritance hierarchies), it will need to create some sort of handshake to get out of the old code before the new code is loaded. (See SystemDictionary::add_to_hierarchy in the JVM.) This requires a safepoint mechanism of some sort to make sure that all threads are blocked from entering call sites to old targets, and/or roll forward out of such call sites. Generally, only the JVM knows enough about each thread to make this happen, hence the need for a bulk invalidation API. I'm thinking that the language runtime will do the following to implement a change to an unchecked quasi-invariant: 1. grab a lock on the variable global state (e.g., class hierarchy) 2. compute a limited set of call sites to invalidated, based on language-specific dependency tables 3. call the 292 API to bulk-invalidate those call sites 4. make the change to the variable global state 5. eagerly patch invalidated call sites, if desired, and/or respond to bootstrap requests (which can interact with the global lock) 6. release the lock 7. recover from any remaining consequences incrementally, as bootstrap methods are called on invalidated call sites Step 3 is magic and expensive. It may invalidate "innocent bystander", call sites which are not actually invalid. It will at least make sure that any pending dynamic calls at the invalid call sites are fully executed, up to a global synchronization point that it defines internally. However, after step 3, there may well be old methods on the stack. For example, a dynamic call might have completed to an outdated It is up to the language runtime to cope with these. We come back to the need to have self-verifying or self-correcting target methods. In fact, the whole bulk invalidation API could be unnecessary, given that target methods must always be self-verifying anyway. However, I think it will simplify the self-verification tests, for some languages. BTW, in HotSpot compiled methods are self-correcting, in that they can be deoptimized at any time, replaced by interpreted code, which is less optimal but more robustly correct. I'm trying to stay away from defining such a mechanism above the level of bytecodes, because I don't see how to define and implement it simply. The "hook" you get now for this behavior is to generate an explicit slow-patch check in the bytecodes. By that I mean a test which always succeeds, until the quasi-invariant fails. The JIT is likely to notice (from the profile) that the check "always" succeeds, and compile it to an "uncommon trap", a dead-end in the compiled code which deoptimizes and jumps back to the interpreter. The JIT does not compile anything downstream of the uncommon trap, and so the cleanup does not affect the optimization of the fast path. As long as only the fast path is taken, the specialized JIT code rules. >> Note that the JVM reads the target field in a specialized way, not >> necessarily through a bytecode. Also, the writes to the target field >> go through an accessor, so once again, the volatility of the field >> does not necessarily matter. > not agree, if the accessor is inlined, target can be not reloaded from > the RAM. The point is, the accessor can have the required memory barrier (e.g., from Unsafe, or an empty synch) without marking the field volatile. >> Maybe the right thing to do is move target into a mixin-style >> superclass, java.dyn.impl.CS, and have it be volatile in the >> backport. >> > I'am not sure you can avoid the volatile read. I'm not yet sure that the volatile read even does what you hope it does! See above. > You don't need protected field if you have accessors. And currently > those accessors exist. Right, except for CallSite.callerObject. > Why not use a static final field, like the anonk code already does ? > and detect at runtime if there is a native impl or if the backport > must be used. That doesn't let you mix in JVM-specific fields like a superclass does. 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/20090421/477e652f/attachment.html From John.Rose at Sun.COM Wed Apr 22 00:29:52 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 22 Apr 2009 00:29:52 -0700 Subject: thanks, and MOP stuff Message-ID: <07B85C93-387B-4563-B082-5663D5006C00@sun.com> Thanks, Attila, for jumping in with the MVLM build stuff. The bulk of the meth and indy bits are moving slowly but surely into the regular JDK7 builds, so I expect the delta between JDK7 and MLVM will decrease rapidly. Note that most of meth.patch is now integrated in http://hg.openjdk.java.net/jdk7/jdk7/hotspot/ so it will show up in a weekly build shortly. Also, indy has been cleared for take-off. But, with bug fixes and late alterations, that delta between JDK7 and MLVM will remain non-zero for much of this year, so what you are doing will remain very (very!) helpful. Best wishes, -- John From szegedia at gmail.com Wed Apr 22 01:28:15 2009 From: szegedia at gmail.com (Attila Szegedi) Date: Wed, 22 Apr 2009 10:28:15 +0200 Subject: thanks, and MOP stuff In-Reply-To: <07B85C93-387B-4563-B082-5663D5006C00@sun.com> References: <07B85C93-387B-4563-B082-5663D5006C00@sun.com> Message-ID: On 2009.04.22., at 9:29, John Rose wrote: > Thanks, Attila, for jumping in with the MVLM build stuff. Well, I needed it, and once built, it's a no-brainer to put it out there, so... > The bulk of the meth and indy bits are moving slowly but surely into > the regular JDK7 builds, so I expect the delta between JDK7 and MLVM > will decrease rapidly. Note that most of meth.patch is now > integrated in http://hg.openjdk.java.net/jdk7/jdk7/hotspot/ so it > will show up in a weekly build shortly. Also, indy has been cleared > for take-off. > > But, with bug fixes and late alterations, that delta between JDK7 > and MLVM will remain non-zero for much of this year, so what you are > doing will remain very (very!) helpful. Sure - I'll repeat the build from time to time, probably on weekends. Attila. > > Best wishes, > -- John From benjamin.john.evans at googlemail.com Wed Apr 22 01:39:06 2009 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Wed, 22 Apr 2009 09:39:06 +0100 Subject: London group looking at "perl" on the MLVM Message-ID: <38a53eb30904220139k3196d628t91d6f46b660a191a@mail.gmail.com> Hi, A small group of developers in London are starting to look at implementing a version of perl on the MLVM. We're aware that we're likely to have both syntactic and semantic issues (due to perl's somewhat idiosyncratic nature) but we thought we'd try anyway, and just see how far we can get and what we learn along the way. I've posted about it here: http://boxcatjunction.blogspot.com/2009/04/state-of-play-for-perlish-poc.htmland including links to a talk I gave to London.pm (the London Perl Users Group) last week. We're organising a date to get together in real life and hack on this - and just wanted to throw the invitation open to anyone on these lists who wanted to come along and help - or just exchange information and understanding about the new dynamic features that we're leveraging. Please mail me offlist if you'd like to come along, and let's work on a list of dates. Charlie: Do you think anyone on the jruby list might be interested? I've certainly learned a lot from our conversations and from reading the jruby source, but didn't want to crosspost to too many groups at once. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090422/215d9d33/attachment.html From pdoubleya at gmail.com Wed Apr 22 02:01:06 2009 From: pdoubleya at gmail.com (Patrick Wright) Date: Wed, 22 Apr 2009 11:01:06 +0200 Subject: London group looking at "perl" on the MLVM In-Reply-To: <38a53eb30904220139k3196d628t91d6f46b660a191a@mail.gmail.com> References: <38a53eb30904220139k3196d628t91d6f46b660a191a@mail.gmail.com> Message-ID: <64efa1ba0904220201x7a18e375r5e8723158c373ade@mail.gmail.com> Hi I saw the announcement and your slides; wondering if you'd been in touch with Bradley Kuhn? He was looking at this [1] several years ago. Apart from his thesis, I remember coming across a number of posts by him on Kawa and Perl mailing lists, if I'm not mistaken. Regards Patrick 1: http://www.ebb.org/bkuhn/writings/technical/thesis/thesis-html.html From John.Rose at Sun.COM Wed Apr 22 10:44:03 2009 From: John.Rose at Sun.COM (John Rose) Date: Wed, 22 Apr 2009 10:44:03 -0700 Subject: progress: indy.patch -> JDK7 Message-ID: <4F575E06-34DC-43C1-98EF-4007915B083F@sun.com> The majority of indy.patch has entered the JDK7 VM at my workgroup's integration repo, today at about 4:00AM PDT: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/be93aad57795 More to come, as we hammer on the spec, Java API, and initial apps. -- John From john.rose at sun.com Wed Apr 22 19:16:27 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Thu, 23 Apr 2009 02:16:27 +0000 Subject: hg: mlvm/mlvm/hotspot: indy: update patch repo consistently with today's push to JDK7 of 6655646 Message-ID: <20090423021628.3D9EFE59C@hg.openjdk.java.net> Changeset: 5cb83bb7bf49 Author: jrose Date: 2009-04-22 19:13 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5cb83bb7bf49 indy: update patch repo consistently with today's push to JDK7 of 6655646 ! indy-6655646.patch < indy.patch + indy-amd64.patch + indy-sparc.patch + indy.patch ! series From john.rose at sun.com Wed Apr 22 20:46:09 2009 From: john.rose at sun.com (john.rose at sun.com) Date: Thu, 23 Apr 2009 03:46:09 +0000 Subject: hg: mlvm/mlvm/hotspot: indy: move platform-specific code from meth.patch into indy-$arch.patch Message-ID: <20090423034610.4FE8AE5B5@hg.openjdk.java.net> Changeset: 40852f028895 Author: jrose Date: 2009-04-22 20:43 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/40852f028895 indy: move platform-specific code from meth.patch into indy-$arch.patch ! indy-amd64.patch ! indy-sparc.patch ! indy.patch ! meth.patch ! series From charles.nutter at sun.com Wed Apr 22 22:21:32 2009 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 23 Apr 2009 07:21:32 +0200 Subject: progress: indy.patch -> JDK7 In-Reply-To: <4F575E06-34DC-43C1-98EF-4007915B083F@sun.com> References: <4F575E06-34DC-43C1-98EF-4007915B083F@sun.com> Message-ID: <49EFFADC.9010607@sun.com> John Rose wrote: > The majority of indy.patch has entered the JDK7 VM at my workgroup's > integration repo, today at about 4:00AM PDT: > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/be93aad57795 > > More to come, as we hammer on the spec, Java API, and initial apps. Big congratulations on this :) The dream is becoming a reality! I'm all done with my keynote at JAX (which went really well) and will be splitting my remaining time in Mainz between sightseeing and indy hacking. - Charlie From chanwit at gmail.com Thu Apr 23 12:56:34 2009 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Thu, 23 Apr 2009 20:56:34 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <49EC53CE.8010807@univ-mlv.fr> References: <49BD4FD6.4080306@sun.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> <49EB6D55.8070108@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> <49EC53CE.8010807@univ-mlv.fr> Message-ID: <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> Hello Remi, I could not manage to build it on Fedora 8. The bsd-port branch won't compile there. The jdk7 branch compiles there, but I could not get it patched. Do you have any patching trick to share ? Best regards, Chanwit On Mon, Apr 20, 2009 at 11:51 AM, R?mi Forax wrote: > Tobias Ivarsson a ?crit : >> Just thought I'd download the binaries and see if they worked on Mac >> OS 10.4: >> >> ~/Desktop/j2sdk-image tobias$ ./bin/java -version >> Bus error >> >> So I guess I'll stick with Linux, hope that the current focus on being >> able to build the MLVM on Mac doesn't make it unbuildable on Linux >> systems. > Currently, it's buildable on my fedora 10 :) >> >> /Tobias > R?mi >> >> On Sun, Apr 19, 2009 at 9:40 PM, Attila Szegedi > > wrote: >> >> ? ? Okay, in the end, I didn't really name it, I just use "mlvm" >> >> ? ? So, an binary build of MLVM for Mac OS X 10.5.x on Intel processors is >> ? ? now available here: >> >> ? ? >> >> ? ? When you unpack it, it will create a directory named "j2sdk_image". >> ? ? Use at your own risk :-) Seriously, I barely had time to try whether >> ? ? it works at all, but if I accidentally bungled anything, I'll build >> ? ? and publish a new version and post an update message here. >> >> ? ? Attila. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Thu Apr 23 13:09:05 2009 From: thobes at gmail.com (Tobias Ivarsson) Date: Thu, 23 Apr 2009 22:09:05 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> <49EB6D55.8070108@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> <49EC53CE.8010807@univ-mlv.fr> <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> Message-ID: <9997d5e60904231309v75a2c5b1ub1346232adfdbc22@mail.gmail.com> Hi, It's great that we have people building on many different platforms. The bsd-port should build on linux-platforms as well. Although I still have some problems with my build on Ubuntu 8.10. If you could please share what failures you are experiencing in your build we could better find out how to solve it. As for my problems I still have some things that I am going to try. Cheers, Tobias On Thu, Apr 23, 2009 at 9:56 PM, Chanwit Kaewkasi wrote: > Hello Remi, > > I could not manage to build it on Fedora 8. > The bsd-port branch won't compile there. The jdk7 branch compiles > there, but I could not get it patched. > Do you have any patching trick to share ? > > Best regards, > > Chanwit > > On Mon, Apr 20, 2009 at 11:51 AM, R?mi Forax wrote: > > Tobias Ivarsson a ?crit : > >> Just thought I'd download the binaries and see if they worked on Mac > >> OS 10.4: > >> > >> ~/Desktop/j2sdk-image tobias$ ./bin/java -version > >> Bus error > >> > >> So I guess I'll stick with Linux, hope that the current focus on being > >> able to build the MLVM on Mac doesn't make it unbuildable on Linux > >> systems. > > Currently, it's buildable on my fedora 10 :) > >> > >> /Tobias > > R?mi > >> > >> On Sun, Apr 19, 2009 at 9:40 PM, Attila Szegedi >> > wrote: > >> > >> Okay, in the end, I didn't really name it, I just use "mlvm" > >> > >> So, an binary build of MLVM for Mac OS X 10.5.x on Intel processors > is > >> now available here: > >> > >> < > http://dl.getdropbox.com/u/362958/mlvm/mlvm-macosx-i586-20090419.tgz> > >> > >> When you unpack it, it will create a directory named "j2sdk_image". > >> Use at your own risk :-) Seriously, I barely had time to try whether > >> it works at all, but if I accidentally bungled anything, I'll build > >> and publish a new version and post an update message here. > >> > >> Attila. > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090423/d09e07c2/attachment.html From chanwit at gmail.com Thu Apr 23 13:23:53 2009 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Thu, 23 Apr 2009 21:23:53 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <9997d5e60904231309v75a2c5b1ub1346232adfdbc22@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> <49EB6D55.8070108@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> <49EC53CE.8010807@univ-mlv.fr> <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> <9997d5e60904231309v75a2c5b1ub1346232adfdbc22@mail.gmail.com> Message-ID: <25ff69410904231323g59ed7658u81b67d1fea2c9c84@mail.gmail.com> Hello Tobias, Here's my error message: In file included from ../../../src/share/native/java/lang/fdlibm/src/k_standard.c:27In file included from ../../../src/share/native/java/lang/fdlibm/src/k_rem_pio2.c:143: ../../../src/share/native/java/lang/fdlibm/include/fdlibm.h:30:28: error: machine/endian.h: No such file or directory : ../../../src/share/native/java/lang/fdlibm/include/fdlibm.h:30:28: error: machine/endian.h: No such file or directory make[5]: *** [/opt/openjdk/bsd-port/build/linux-i586/tmp/java/fdlibm/obj/k_rem_pio2.o] Error 1 make[5]: *** Waiting for unfinished jobs.... make[5]: *** [/opt/openjdk/bsd-port/build/linux-i586/tmp/java/fdlibm/obj/k_standard.o] Error 1 make[5]: Leaving directory `/opt/openjdk/bsd-port/jdk/make/java/fdlibm' make[4]: *** [library_parallel_compile] Error 2 make[4]: Leaving directory `/opt/openjdk/bsd-port/jdk/make/java/fdlibm' make[3]: *** [all] Error 1 make[3]: Leaving directory `/opt/openjdk/bsd-port/jdk/make/java' make[2]: *** [all] Error 1 make[2]: Leaving directory `/opt/openjdk/bsd-port/jdk/make' make[1]: *** [jdk-build] Error 2 make[1]: Leaving directory `/opt/openjdk/bsd-port' It seems machine/endian.h does not exist on my machine. But I do not know which addition libs I need to install to make this compile. Best regards, Chanwit On Thu, Apr 23, 2009 at 9:09 PM, Tobias Ivarsson wrote: > Hi, > > It's great that we have people building on many different platforms. > > The bsd-port should build on linux-platforms as well. Although I still have > some problems with my build on Ubuntu 8.10. > > If you could please share what failures you are experiencing in your build > we could better find out how to solve it. > > As for my problems I still have some things that I am going to try. > > Cheers, > Tobias > > On Thu, Apr 23, 2009 at 9:56 PM, Chanwit Kaewkasi wrote: >> >> Hello Remi, >> >> I could not manage to build it on Fedora 8. >> The bsd-port branch won't compile there. The jdk7 branch compiles >> there, but I could not get it patched. >> Do you have any patching trick to share ? >> >> Best regards, >> >> Chanwit >> >> On Mon, Apr 20, 2009 at 11:51 AM, R?mi Forax wrote: >> > Tobias Ivarsson a ?crit : >> >> Just thought I'd download the binaries and see if they worked on Mac >> >> OS 10.4: >> >> >> >> ~/Desktop/j2sdk-image tobias$ ./bin/java -version >> >> Bus error >> >> >> >> So I guess I'll stick with Linux, hope that the current focus on being >> >> able to build the MLVM on Mac doesn't make it unbuildable on Linux >> >> systems. >> > Currently, it's buildable on my fedora 10 :) >> >> >> >> /Tobias >> > R?mi >> >> >> >> On Sun, Apr 19, 2009 at 9:40 PM, Attila Szegedi > >> > wrote: >> >> >> >> ? ? Okay, in the end, I didn't really name it, I just use "mlvm" >> >> >> >> ? ? So, an binary build of MLVM for Mac OS X 10.5.x on Intel processors >> >> is >> >> ? ? now available here: >> >> >> >> >> >> >> >> >> >> ? ? When you unpack it, it will create a directory named "j2sdk_image". >> >> ? ? Use at your own risk :-) Seriously, I barely had time to try >> >> whether >> >> ? ? it works at all, but if I accidentally bungled anything, I'll build >> >> ? ? and publish a new version and post an update message here. >> >> >> >> ? ? Attila. >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> >> 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 > > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > From thobes at gmail.com Thu Apr 23 13:34:06 2009 From: thobes at gmail.com (Tobias Ivarsson) Date: Thu, 23 Apr 2009 22:34:06 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <25ff69410904231323g59ed7658u81b67d1fea2c9c84@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> <49EB6D55.8070108@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> <49EC53CE.8010807@univ-mlv.fr> <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> <9997d5e60904231309v75a2c5b1ub1346232adfdbc22@mail.gmail.com> <25ff69410904231323g59ed7658u81b67d1fea2c9c84@mail.gmail.com> Message-ID: <9997d5e60904231334x2ce11607j21be64ac491dd4e2@mail.gmail.com> On Thu, Apr 23, 2009 at 10:23 PM, Chanwit Kaewkasi wrote: > Hello Tobias, > > Here's my error message: > > In file included from > ../../../src/share/native/java/lang/fdlibm/src/k_standard.c:27In file > included from > ../../../src/share/native/java/lang/fdlibm/src/k_rem_pio2.c:143: > ../../../src/share/native/java/lang/fdlibm/include/fdlibm.h:30:28: > error: machine/endian.h: No such file or directory > : > ../../../src/share/native/java/lang/fdlibm/include/fdlibm.h:30:28: > error: machine/endian.h: No such file or directory > make[5]: *** > [/opt/openjdk/bsd-port/build/linux-i586/tmp/java/fdlibm/obj/k_rem_pio2.o] > Error 1 > make[5]: *** Waiting for unfinished jobs.... > make[5]: *** > [/opt/openjdk/bsd-port/build/linux-i586/tmp/java/fdlibm/obj/k_standard.o] > Error 1 > make[5]: Leaving directory `/opt/openjdk/bsd-port/jdk/make/java/fdlibm' > make[4]: *** [library_parallel_compile] Error 2 > make[4]: Leaving directory `/opt/openjdk/bsd-port/jdk/make/java/fdlibm' > make[3]: *** [all] Error 1 > make[3]: Leaving directory `/opt/openjdk/bsd-port/jdk/make/java' > make[2]: *** [all] Error 1 > make[2]: Leaving directory `/opt/openjdk/bsd-port/jdk/make' > make[1]: *** [jdk-build] Error 2 > make[1]: Leaving directory `/opt/openjdk/bsd-port' > > It seems machine/endian.h does not exist on my machine. But I do not > know which addition libs I need to install to make this compile. > Yes, that is the same error I got when using the same build process that worked for building the jdk7 branch for building the bsd-port branch. Do anyone know if the bsd-port needs some different kind of hand holding when building on linux, compared to the jdk7 branch? Cheers, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090423/57b678db/attachment.html From chanwit at gmail.com Thu Apr 23 14:55:45 2009 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Thu, 23 Apr 2009 22:55:45 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <9997d5e60904231334x2ce11607j21be64ac491dd4e2@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <49EB6D55.8070108@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> <49EC53CE.8010807@univ-mlv.fr> <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> <9997d5e60904231309v75a2c5b1ub1346232adfdbc22@mail.gmail.com> <25ff69410904231323g59ed7658u81b67d1fea2c9c84@mail.gmail.com> <9997d5e60904231334x2ce11607j21be64ac491dd4e2@mail.gmail.com> Message-ID: <25ff69410904231455v7b44bbc6v1be21d53c468c779@mail.gmail.com> Updated: I have managed to fix it per this: http://archives.neohapsis.com/archives/openbsd/2004-01/0356.html by simply commenting the include statements out. Cheers, Chanwit On Thu, Apr 23, 2009 at 9:34 PM, Tobias Ivarsson wrote: > > Yes, that is the same error I got when using the same build process that > worked for building the jdk7 branch for building the bsd-port branch. > Do anyone know if the bsd-port needs some different kind of hand holding > when building on linux, compared to the jdk7 branch? > > Cheers, > Tobias > > _______________________________________________ > 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 Thu Apr 23 16:27:45 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 24 Apr 2009 01:27:45 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <7DE81BEC-6475-4DBB-99C0-4290DB8EDDC6@sun.com> <49DF99B4.3090109@sun.com> <36BDFDC8-D003-401B-A776-F3C7F6524F26@sun.com> <16A38946-AC73-49DD-BE36-BC80F63E5FB0@gmail.com> <49EB6D55.8070108@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> <49EC53CE.8010807@univ-mlv.fr> <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> Message-ID: <49F0F971.1060303@univ-mlv.fr> Chanwit Kaewkasi a ?crit : > Hello Remi, > > I could not manage to build it on Fedora 8. > The bsd-port branch won't compile there. The jdk7 branch compiles > there, but I could not get it patched. > Do you have any patching trick to share ? > Not really, I have cloned the bsd port workspace, applied the changes from le mlvm workspace and then compile. When I haven't tried to compile the indy patch. I have de-activated it because the VM code and the Java code was not aligned. It was before the patches posted yesterday. > Best regards, > > Chanwit > regards, R?mi From chanwit at gmail.com Fri Apr 24 03:22:05 2009 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Fri, 24 Apr 2009 11:22:05 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <25ff69410904231455v7b44bbc6v1be21d53c468c779@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <38a53eb30904191141w2e1e8525t67a7dfc987a862e8@mail.gmail.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> <49EC53CE.8010807@univ-mlv.fr> <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> <9997d5e60904231309v75a2c5b1ub1346232adfdbc22@mail.gmail.com> <25ff69410904231323g59ed7658u81b67d1fea2c9c84@mail.gmail.com> <9997d5e60904231334x2ce11607j21be64ac491dd4e2@mail.gmail.com> <25ff69410904231455v7b44bbc6v1be21d53c468c779@mail.gmail.com> Message-ID: <25ff69410904240322m50486d65rd485d77dd7be0dc7@mail.gmail.com> More update, I am now stuck at this error, while compiling the bsd-port: error: class file for com.sun.jmx.snmp.Timestamp not found 1 error make[2]: *** [initial-image-jdk] Error 1 make[2]: Leaving directory `/opt/openjdk/bsd-port/jdk/make' make[1]: *** [jdk-build] Error 2 make[1]: Leaving directory `/opt/openjdk/bsd-port' The bootstrap jdk I'm using is Sun JDK 1.6.0_04-b12. Not sure if it's causing this error? Any suggestion would be great. Best regards, Chanwit On Thu, Apr 23, 2009 at 10:55 PM, Chanwit Kaewkasi wrote: > Updated: > I have managed to fix it per this: > http://archives.neohapsis.com/archives/openbsd/2004-01/0356.html > by simply commenting the include statements out. > > Cheers, > > Chanwit > > On Thu, Apr 23, 2009 at 9:34 PM, Tobias Ivarsson wrote: >> >> Yes, that is the same error I got when using the same build process that >> worked for building the jdk7 branch for building the bsd-port branch. >> Do anyone know if the bsd-port needs some different kind of hand holding >> when building on linux, compared to the jdk7 branch? >> >> Cheers, >> Tobias >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev at openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> > -- Chanwit Kaewkasi PhD Candidate, Centre for Novel Computing School of Computer Science The University of Manchester Oxford Road Manchester M13 9PL, UK From scheme.mlvm at gmail.com Fri Apr 24 04:47:08 2009 From: scheme.mlvm at gmail.com (scheme mlvm) Date: Fri, 24 Apr 2009 13:47:08 +0200 Subject: Latest instructions on getting and patching In-Reply-To: <25ff69410904240322m50486d65rd485d77dd7be0dc7@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> <49EC53CE.8010807@univ-mlv.fr> <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> <9997d5e60904231309v75a2c5b1ub1346232adfdbc22@mail.gmail.com> <25ff69410904231323g59ed7658u81b67d1fea2c9c84@mail.gmail.com> <9997d5e60904231334x2ce11607j21be64ac491dd4e2@mail.gmail.com> <25ff69410904231455v7b44bbc6v1be21d53c468c779@mail.gmail.com> <25ff69410904240322m50486d65rd485d77dd7be0dc7@mail.gmail.com> Message-ID: <488dde700904240447w2e88a474i671c288b67df125d@mail.gmail.com> My experiences with building mlvm based on bsd-port: On missing machine/endian.h if build on linux (FC10 in my case): In jdk: replace with #include On error: class file for com.sun.jmx.snmp.Timestamp not found: Build does not extract a few binary plug classes, fix jdk: make/common/internal/BinaryPlugs.gmk To-be-encountered :): on NullPointerException for jar tool with at listOfFilesparam: In jdk, src/share/classes/sun/tools/jar/Main.java: set new cwd property before any of the extract() method is called (not only in one extract() method) If using newly build openjdk-1.7.0 as ALT_BOOTDIR, javadoc vm crashes when building certain docs. seemed to happen randomly, no fix, just workaround: In jdk, make/common/shared/Defs-java.gmk: introduced new ALT_JAVADOC to use jdk 6 javadoc Patch files attached fyi, J?rgen 2009/4/24 Chanwit Kaewkasi > More update, I am now stuck at this error, while compiling the bsd-port: > > error: class file for com.sun.jmx.snmp.Timestamp not found > 1 error > make[2]: *** [initial-image-jdk] Error 1 > make[2]: Leaving directory `/opt/openjdk/bsd-port/jdk/make' > make[1]: *** [jdk-build] Error 2 > make[1]: Leaving directory `/opt/openjdk/bsd-port' > > The bootstrap jdk I'm using is Sun JDK 1.6.0_04-b12. Not sure if it's > causing this error? > > Any suggestion would be great. > > Best regards, > > Chanwit > > On Thu, Apr 23, 2009 at 10:55 PM, Chanwit Kaewkasi > wrote: > > Updated: > > I have managed to fix it per this: > > http://archives.neohapsis.com/archives/openbsd/2004-01/0356.html > > by simply commenting the include statements out. > > > > Cheers, > > > > Chanwit > > > > On Thu, Apr 23, 2009 at 9:34 PM, Tobias Ivarsson > wrote: > >> > >> Yes, that is the same error I got when using the same build process that > >> worked for building the jdk7 branch for building the bsd-port branch. > >> Do anyone know if the bsd-port needs some different kind of hand holding > >> when building on linux, compared to the jdk7 branch? > >> > >> Cheers, > >> Tobias > >> > >> _______________________________________________ > >> mlvm-dev mailing list > >> mlvm-dev at openjdk.java.net > >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >> > > > > > > -- > Chanwit Kaewkasi > PhD Candidate, > Centre for Novel Computing > School of Computer Science > The University of Manchester > Oxford Road > Manchester > M13 9PL, UK > _______________________________________________ > 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/20090424/9e45460a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: interim-endian.patch Type: text/x-patch Size: 1581 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090424/9e45460a/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: jmx.snmp-binaryplugs.patch Type: text/x-patch Size: 742 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090424/9e45460a/attachment-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: sun-tools-jar.patch Type: text/x-patch Size: 1396 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090424/9e45460a/attachment-0002.bin From forax at univ-mlv.fr Fri Apr 24 05:12:22 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 24 Apr 2009 14:12:22 +0200 Subject: Ask for a patch review: CallSite.target is not volatile In-Reply-To: <37655E35-26E4-482C-A542-A69426B02D38@sun.com> References: <48D2E6F2.404@univ-mlv.fr> <37655E35-26E4-482C-A542-A69426B02D38@sun.com> Message-ID: <49F1ACA6.1000207@univ-mlv.fr> John Rose a ?crit : > I'm gathering up issues from old mail, and found the incomplete > exchange below on the mlvm dev list. > > I've followed your advice and removed the "protected" keyword from > CallSite fields. The accessors are sufficient. > > I'm also going to remove the single-inheritance mixin pattern which > you objected to, since IBM has also objected to it (on the EG). > Basically, I'm going to have the JVM special-case MethodHandle > instead of a superclass sun.dyn.MethodHandleImpl. Great, I always had a bad feeling about this design. > > (My English teacher in high school used to say, "kill your darlings", > meaning that, if you have a bit of writing you think particularly > clever, you probably need to edit it.) I've already heard this expression about a piece of code, but I'm not able to remember where and when. Nevertheless, it seems to be a good principle. > > I've raised the issues about target invalidation with the EG. Are > there other issues in the exchange below that we should call out? No, the main purpose of that thread was volatile target and invalidation > > Thanks, > -- John cheers, R?mi From chanwit at gmail.com Fri Apr 24 07:35:29 2009 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Fri, 24 Apr 2009 15:35:29 +0100 Subject: Latest instructions on getting and patching In-Reply-To: <488dde700904240447w2e88a474i671c288b67df125d@mail.gmail.com> References: <49BD4FD6.4080306@sun.com> <9997d5e60904200331k5bb32889l3f44a5d6fe433681@mail.gmail.com> <49EC53CE.8010807@univ-mlv.fr> <25ff69410904231256x457eb6e1n10a5db66de3a50d7@mail.gmail.com> <9997d5e60904231309v75a2c5b1ub1346232adfdbc22@mail.gmail.com> <25ff69410904231323g59ed7658u81b67d1fea2c9c84@mail.gmail.com> <9997d5e60904231334x2ce11607j21be64ac491dd4e2@mail.gmail.com> <25ff69410904231455v7b44bbc6v1be21d53c468c779@mail.gmail.com> <25ff69410904240322m50486d65rd485d77dd7be0dc7@mail.gmail.com> <488dde700904240447w2e88a474i671c288b67df125d@mail.gmail.com> Message-ID: <25ff69410904240735t4ce790boc5bd5e417a2b154f@mail.gmail.com> Hello J?rgen, Thanks for patches :) It's compiled successfully now. Best regards, Chanwit On Fri, Apr 24, 2009 at 12:47 PM, scheme mlvm wrote: > My experiences with building mlvm based on bsd-port: > > On missing machine/endian.h if build on linux (FC10 in my case): > In jdk: replace with #include > > On error: class file for com.sun.jmx.snmp.Timestamp not found: > Build does not extract a few binary plug classes, fix jdk: > make/common/internal/BinaryPlugs.gmk > > To-be-encountered :): on NullPointerException for jar tool with at listOfFiles > param: > In jdk, src/share/classes/sun/tools/jar/Main.java: set new cwd property > before any of the extract() method is called (not only in one extract() > method) > > If using newly build openjdk-1.7.0 as ALT_BOOTDIR, javadoc vm crashes when > building certain docs. seemed to happen randomly, no fix, just workaround: > In jdk, make/common/shared/Defs-java.gmk: introduced new ALT_JAVADOC to use > jdk 6 javadoc > > Patch files attached > > fyi, J?rgen > > 2009/4/24 Chanwit Kaewkasi >> >> More update, I am now stuck at this error, while compiling the bsd-port: >> >> error: class file for com.sun.jmx.snmp.Timestamp not found >> 1 error >> make[2]: *** [initial-image-jdk] Error 1 >> make[2]: Leaving directory `/opt/openjdk/bsd-port/jdk/make' >> make[1]: *** [jdk-build] Error 2 >> make[1]: Leaving directory `/opt/openjdk/bsd-port' >> >> The bootstrap jdk I'm using is Sun JDK 1.6.0_04-b12. Not sure if it's >> causing this error? >> >> Any suggestion would be great. >> >> Best regards, >> >> Chanwit >> >> On Thu, Apr 23, 2009 at 10:55 PM, Chanwit Kaewkasi >> wrote: >> > Updated: >> > I have managed to fix it per this: >> > http://archives.neohapsis.com/archives/openbsd/2004-01/0356.html >> > by simply commenting the include statements out. >> > >> > Cheers, >> > >> > Chanwit >> > >> > On Thu, Apr 23, 2009 at 9:34 PM, Tobias Ivarsson >> > wrote: >> >> >> >> Yes, that is the same error I got when using the same build process >> >> that >> >> worked for building the jdk7 branch for building the bsd-port branch. >> >> Do anyone know if the bsd-port needs some different kind of hand >> >> holding >> >> when building on linux, compared to the jdk7 branch? >> >> >> >> Cheers, >> >> Tobias >> >> >> >> _______________________________________________ >> >> mlvm-dev mailing list >> >> mlvm-dev at openjdk.java.net >> >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev >> >> >> > >> >> >> >> -- >> Chanwit Kaewkasi >> PhD Candidate, >> Centre for Novel Computing >> School of Computer Science >> The University of Manchester >> Oxford Road >> Manchester >> M13 9PL, UK >> _______________________________________________ >> 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 forax at univ-mlv.fr Mon Apr 27 17:06:04 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 28 Apr 2009 02:06:04 +0200 Subject: Bug in java.dyn.MethodHandles.unreflect Message-ID: <49F6486C.4080605@univ-mlv.fr> There is a bug in the Java API, in MethodHandles.unreflect (the private one): Exception in thread "main" java.lang.NullPointerException at java.dyn.MethodHandles.unreflect(MethodHandles.java:294) at java.dyn.MethodHandles.unreflect(MethodHandles.java:222) at fr.umlv.indy.visitor.AbstractVisitor.(AbstractVisitor.java:33) at fr.umlv.indy.visitor.test.Main$1.(Main.java:7) at fr.umlv.indy.visitor.test.Main.main(Main.java:7) VerifyAccess.isAccessible can return null, but the following line doesn't test null. if (constraint != defc && !constraint.isAssignableFrom(defc)) { oups ----------^ R?mi From forax at univ-mlv.fr Tue Apr 28 08:03:26 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 28 Apr 2009 17:03:26 +0200 Subject: Mistmatch hotspot/jdk when calling sun.dyn.CallSiteImpl.makeSite Message-ID: <49F71ABE.30100@univ-mlv.fr> Hi John, hi all, I was trying to use the build from the hotspot repository (not the mlvm one) with the jdk classes from the mlvm repository. It works with one exception, the hotspot code look for a method to create a call site java.dyn.CallSite.makeSite(Ljava/lang/Class;Ljava/lang/String;Ljava/dyn/MethodType;II)Ljava/dyn/CallSite; but in the current jdk code, the method makeSite() has a different return type: sun.dyn.CallSiteImpl.makeSite(Ljava/lang/Class;Ljava/lang/String;Ljava/dyn/MethodType;II)Ljava/dyn/CallSite; perhaps this mismatch is already corrected in the mlvm hotspot code. R?mi From chanwit at gmail.com Tue Apr 28 08:02:11 2009 From: chanwit at gmail.com (Chanwit Kaewkasi) Date: Tue, 28 Apr 2009 16:02:11 +0100 Subject: Mistmatch hotspot/jdk when calling sun.dyn.CallSiteImpl.makeSite In-Reply-To: <49F71ABE.30100@univ-mlv.fr> References: <49F71ABE.30100@univ-mlv.fr> Message-ID: <25ff69410904280802l36d460aas840dc6759a1ebc21@mail.gmail.com> I confirm this exception. Making change from CallSiteImpl to CallSite works fine for me. Best regards, Chanwit On Tue, Apr 28, 2009 at 4:03 PM, R?mi Forax wrote: > Hi John, hi all, > I was trying to use the build from the hotspot repository (not the mlvm one) > with the jdk classes from the mlvm repository. > > It works with one exception, the hotspot code look for a method > to create a call site > java.dyn.CallSite.makeSite(Ljava/lang/Class;Ljava/lang/String;Ljava/dyn/MethodType;II)Ljava/dyn/CallSite; > > but in the current jdk code, the method makeSite() has a different > return type: > sun.dyn.CallSiteImpl.makeSite(Ljava/lang/Class;Ljava/lang/String;Ljava/dyn/MethodType;II)Ljava/dyn/CallSite; > > perhaps this mismatch is already corrected in the mlvm hotspot code. > > R?mi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev at openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > -- Chanwit Kaewkasi PhD Candidate, Centre for Novel Computing School of Computer Science The University of Manchester Oxford Road Manchester M13 9PL, UK