From glewis at eyesbeyond.com Mon Dec 1 11:06:16 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Mon, 1 Dec 2008 11:06:16 -0800 Subject: Latest repo fails to build on OS X In-Reply-To: References: <20081130042444.GA4998@misty.eyesbeyond.com> Message-ID: <20081201190616.GA36457@misty.eyesbeyond.com> On Sun, Nov 30, 2008 at 08:30:06AM -0500, Michael Franz wrote: > > All we have since then are merges from the main OpenJDK repository. > > > > In reference to your follow ups, I can build the code on both FreeBSD/i386 > > and FreeBSD/amd64, so that covers both 32 bit and 64 bit platforms. > > > > I also see from your followups that Mac OS X is 32 bit, so this code will > > end up being > > > > movl(dst, src); > > > > no matter which variant the compiler picks. It should pick the intptr_t > > version though. In fact, on FreeBSD/i386 intptr_t is typedef'ed to > > int32_t, so these are the same. > > > > > I wonder how intptr_t is defined on Mac OS X and what version of gcc is > > being used? You could try changing the cast to (intptr_t) instead of > > (int32_t), since it should basically be the same. > > > > Based on what is in int32_t is a signed int and intptr_t is an > signed long. Apple is using gcc 4.0.1. > > For the original issue I did change the cast from int32_t to intptr_t and it > works, however, there are other issues that follow that related to the same > change. I could go through and change all the places it breaks, but there > must be and easier fix. I agree. The root problem appears to be the assumption that on 32 bit platforms intptr_t and int32_t are typedef'ed to the same thing. This is clearly not the case on Mac OS X. This is something I'd like to take up on the main OpenJDK list since its not BSD specific (it just happens that it only breaks on one of our supported OSes). I'll try and find time to send out an email tonight. -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From Kelly.Ohair at Sun.COM Mon Dec 1 11:23:44 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Mon, 01 Dec 2008 11:23:44 -0800 Subject: Latest repo fails to build on OS X In-Reply-To: <20081201190616.GA36457@misty.eyesbeyond.com> References: <20081130042444.GA4998@misty.eyesbeyond.com> <20081201190616.GA36457@misty.eyesbeyond.com> Message-ID: <493439C0.3010000@sun.com> I don't think anyone can assume that intptr_t will be defined to int32_t or int64_t, it's only requirement is to be able to hold a pointer. Seems like a nasty problem, and if the OpenJDK sources are depending on intptr_t being the same type as int32_t or int64_t, I have to agree that it should be treated as an OpenJDK bug. I think this should go to the hotspot-dev at openjdk.java.net alias, make sure you include the trace: /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp: In member function 'void InterpreterMacroAssembler::empty_expression_stack()': /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:123: error: call of overloaded 'movptr(Address, int)' is ambiguous /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2010: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) /Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2012: note: void MacroAssembler::movptr(Address, RegisterImpl*) make[6]: *** [incls/_precompiled.incl.gch] Error 1 make[5]: *** [the_vm] Error 2 make[4]: *** [product] Error 2 make[3]: *** [generic_build2] Error 2 make[2]: *** [product] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2 -kto Greg Lewis wrote: > On Sun, Nov 30, 2008 at 08:30:06AM -0500, Michael Franz wrote: >>> All we have since then are merges from the main OpenJDK repository. >>> >>> In reference to your follow ups, I can build the code on both FreeBSD/i386 >>> and FreeBSD/amd64, so that covers both 32 bit and 64 bit platforms. >>> >>> I also see from your followups that Mac OS X is 32 bit, so this code will >>> end up being >>> >>> movl(dst, src); >>> >>> no matter which variant the compiler picks. It should pick the intptr_t >>> version though. In fact, on FreeBSD/i386 intptr_t is typedef'ed to >>> int32_t, so these are the same. >>> >>> I wonder how intptr_t is defined on Mac OS X and what version of gcc is >>> being used? You could try changing the cast to (intptr_t) instead of >>> (int32_t), since it should basically be the same. >>> >> Based on what is in int32_t is a signed int and intptr_t is an >> signed long. Apple is using gcc 4.0.1. >> >> For the original issue I did change the cast from int32_t to intptr_t and it >> works, however, there are other issues that follow that related to the same >> change. I could go through and change all the places it breaks, but there >> must be and easier fix. > > I agree. The root problem appears to be the assumption that on 32 bit > platforms intptr_t and int32_t are typedef'ed to the same thing. This > is clearly not the case on Mac OS X. This is something I'd like to take > up on the main OpenJDK list since its not BSD specific (it just happens > that it only breaks on one of our supported OSes). > > I'll try and find time to send out an email tonight. > From swingler at apple.com Tue Dec 2 18:10:12 2008 From: swingler at apple.com (Mike Swingler) Date: Tue, 2 Dec 2008 18:10:12 -0800 Subject: -XstartOnFirstThread for OS X In-Reply-To: References: Message-ID: On Nov 26, 2008, at 8:19 PM, Michael Franz wrote: > Hi, > > I have been thinking about this and have not come up with a way for > SWT to actually put their runloop on thread 0. It is easy enough to > start the JVM on thread 0 but that prevents the changing of the > stack size, at least this is true on linux/solaris. That is true. When we do -XstartOnFirstThread for the SWT, it cannot change the stack size of thread 0, but it is a hard requirement of Mac OS X that events are pumped from thread 0. > Is it good enough to just have the JVM start on the first thread and > then lose the ability to change the JVM's stack size? By design, it is simply the way it must be. > What I have found interesting is that on Leopard using Apple's JDK5 > they spit out a message about setting up for SWT when - > XstartOnFirstThread is passed, but this prevents any Swing > application from working. This does not happen on Tiger with JDK 5. Swing stops working, because -XstartOnFirstThread implies that that someone else (very likely the SWT) is going to come around, and start pumping the event loop on thread 0 with CFRunLoop or the like. It is possible that your testing on Tiger did not actually invoke the - XstartOnFirstThread behavior - we probably relied on other out-of-band information (like environment variables) at the time, or your version of Java was not the latest (it has been a very long time, so I'm not sure what the exact issue on Tiger might be). Cheers, Mike Swingler Java Runtime Engineer Apple Inc. From mvfranz at gmail.com Tue Dec 2 19:27:01 2008 From: mvfranz at gmail.com (Michael Franz) Date: Tue, 2 Dec 2008 22:27:01 -0500 Subject: -XstartOnFirstThread for OS X In-Reply-To: References: Message-ID: On Tue, Dec 2, 2008 at 9:10 PM, Mike Swingler wrote: > On Nov 26, 2008, at 8:19 PM, Michael Franz wrote: > > Hi, >> >> I have been thinking about this and have not come up with a way for SWT to >> actually put their runloop on thread 0. It is easy enough to start the JVM >> on thread 0 but that prevents the changing of the stack size, at least this >> is true on linux/solaris. >> > > That is true. When we do -XstartOnFirstThread for the SWT, it cannot change > the stack size of thread 0, but it is a hard requirement of Mac OS X that > events are pumped from thread 0. > > Is it good enough to just have the JVM start on the first thread and then >> lose the ability to change the JVM's stack size? >> > > By design, it is simply the way it must be. > I have some patches to implement this. There are number of ways to do this and I am sure my first option will not meet everyone's needs. I will send the patch in a different mail. Until we resolve the int32_t vs intptr_t I will not be able to build the latest repo on OS X. So hopefully the patches will still be valid. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081202/0020ddbf/attachment.html From mvfranz at gmail.com Tue Dec 2 19:48:27 2008 From: mvfranz at gmail.com (Michael Franz) Date: Tue, 2 Dec 2008 22:48:27 -0500 Subject: XStartOnFirstThread - Possible Patch Message-ID: Hi, Here is one way of adding -XstartOnFirstThread for OS X. I copied the logic from other parts of the launcher and not too sure if all of the code in the new ContinueInSameThread function is needed. Please review and comment. Thanks Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081202/6f3aa861/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: XstartOnFirstThread.patch Type: application/octet-stream Size: 3194 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081202/6f3aa861/attachment.obj From benjamin.john.evans at googlemail.com Sat Dec 6 04:43:47 2008 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Sat, 6 Dec 2008 12:43:47 +0000 Subject: Dynamic invocation patches on OS X Message-ID: <38a53eb30812060443o6cadf4ddx4897e2ce7e2ccec9@mail.gmail.com> Hi, There has been interest over on the mlvm-dev mailing list (for development of a Java VM which had explicit Multi-Language support - including languages with dynamic dispatch) in getting the dynamic invocation patches for OpenJDK 7 running on OS X. Currently, the application of the patchset produced by John Rose (detailed at http://wikis.sun.com/display/mlvm/Building) is failing on the bsd-port code. Is there anyone on this list who could possibly spare some cycles to help us understand where the patch failures are coming from - and even help fix? I'm quite a newbie at a lot of OpenJDK - but I do have time to devote to trying to fix this. Other people who would directly benefit from having a working patchset include some of the core developers for JRuby - so this would really help out some other projects as well. Thanks in advance, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081206/f7075f7f/attachment.html From stephen.bannasch at deanbrook.org Wed Dec 10 16:32:11 2008 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Wed, 10 Dec 2008 19:32:11 -0500 Subject: problem building openjdk on macos 10.5.5 Message-ID: I'm getting this error: ld: library not found for -ljvm collect2: ld returned 1 exit status This is on MacOS X 10.5.5, (core 2 duo) using soylatte to build. Here's a bunch more detail including the build output echoed to the shell: http://pastie.org/336305 Here's just the end of the build output where the error occurs. Rebuilding /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/libioser12.so because of /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/.files_compiled mapfile-vers /usr/bin/gcc -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN -mstackrealign -Di586 -DARCH='"i586"' -D_ALLBSD_SOURCE -DRELEASE='"1.7.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_REENTRANT -I. -I/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/CClassHeaders -I../../../../src/solaris/javavm/export -I../../../../src/share/javavm/export -I../../../../src/share/javavm/include -I../../../../src/solaris/javavm/include -ICClassHeaders -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/include -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/include/darwin -I../../../../src/share/native/common -I../../../../src/solaris/native/common -I../../../../src/share/native/com/sun/corba/se/internal/io -I../../../../src/solaris/native/com/sun/corba/se/internal/io -L/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386 -dynamiclib -o /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/libioser12.so /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/ioser.o -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386/server -ljvm -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386 -ljava -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386/server -ljvm ld: library not found for -ljvm collect2: ld returned 1 exit status From Kelly.Ohair at Sun.COM Wed Dec 10 17:26:03 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 10 Dec 2008 17:26:03 -0800 Subject: problem building openjdk on macos 10.5.5 In-Reply-To: References: Message-ID: <49406C2B.6090807@sun.com> Does /Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386/server contain a libjvm.so? -kto Stephen Bannasch wrote: > I'm getting this error: > > ld: library not found for -ljvm > collect2: ld returned 1 exit status > > This is on MacOS X 10.5.5, (core 2 duo) using soylatte to build. > > Here's a bunch more detail including the build output echoed to the shell: > > http://pastie.org/336305 > > Here's just the end of the build output where the error occurs. > > Rebuilding > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/libioser12.so > because of > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/.files_compiled > mapfile-vers > /usr/bin/gcc -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused > -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -mstackrealign -Di586 -DARCH='"i586"' -D_ALLBSD_SOURCE > -DRELEASE='"1.7.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE > -D_REENTRANT -I. > -I/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/CClassHeaders > -I../../../../src/solaris/javavm/export > -I../../../../src/share/javavm/export > -I../../../../src/share/javavm/include > -I../../../../src/solaris/javavm/include -ICClassHeaders > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/include > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/include/darwin > -I../../../../src/share/native/common > -I../../../../src/solaris/native/common > -I../../../../src/share/native/com/sun/corba/se/internal/io > -I../../../../src/solaris/native/com/sun/corba/se/internal/io > -L/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386 > -dynamiclib -o > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/libioser12.so > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/ioser.o > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386/server > -ljvm > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386 > -ljava > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386/server > -ljvm > ld: library not found for -ljvm > collect2: ld returned 1 exit status > From stephen.bannasch at deanbrook.org Wed Dec 10 21:39:04 2008 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Thu, 11 Dec 2008 00:39:04 -0500 Subject: problem building openjdk on macos 10.5.5 In-Reply-To: <49406C2B.6090807@sun.com> References: <49406C2B.6090807@sun.com> Message-ID: At 5:26 PM -0800 12/10/08, Kelly O'Hair wrote: >Does > >/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386/server > >contain a libjvm.so? I don't have a jre dir: $ ls -l /Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/ total 40 drwxr-xr-x 40 stephen staff 1360 Mar 25 2008 bin lrwxr-xr-x 1 root staff 60 Jun 28 22:13 bsd-amd64 -> /Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64 drwxr-xr-x 2 stephen staff 68 Mar 25 2008 bundles drwxr-xr-x 9 stephen staff 306 Mar 25 2008 classes drwxr-xr-x 9 stephen staff 306 Mar 25 2008 demo drwxr-xr-x 7 stephen staff 238 Mar 25 2008 gensrc drwxr-xr-x 4 stephen staff 136 Mar 25 2008 hotspot drwxr-xr-x 8 stephen staff 272 Mar 25 2008 include drwxr-xr-x 9 stephen staff 306 Mar 25 2008 j2re-image drwxr-xr-x 3 stephen staff 102 Mar 25 2008 j2sdk-debug-image drwxr-xr-x 15 stephen staff 510 Mar 25 2008 j2sdk-image drwxr-xr-x 2 stephen staff 68 Mar 25 2008 java.net drwxr-xr-x 34 stephen staff 1156 Mar 25 2008 lib drwxr-xr-x 4 stephen staff 136 Mar 25 2008 pack drwxr-xr-x 8 stephen staff 272 Mar 25 2008 sample -rw-r--r-- 1 stephen staff 10713 Mar 25 2008 sanityCheckMessages.txt -rw-r--r-- 1 stephen staff 946 Mar 25 2008 sanityCheckWarnings.txt drwxr-xr-x 2 stephen staff 68 Mar 25 2008 source-bundles drwxr-xr-x 3 stephen staff 102 Mar 25 2008 symbols drwxr-xr-x 54 stephen staff 1836 Mar 25 2008 tmp And there are server files in these directories: [bsd-amd64]$ cd /Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/ [bsd-amd64]$ find . -name server ./classes/com/sun/tools/hat/internal/server ./classes/com/sun/xml/internal/ws/encoding/soap/server ./classes/com/sun/xml/internal/ws/protocol/soap/server ./classes/com/sun/xml/internal/ws/protocol/xml/server ./classes/com/sun/xml/internal/ws/server ./classes/com/sun/xml/internal/ws/transport/http/server ./classes/com/sun/xml/internal/ws/transport/local/server ./classes/java/rmi/server ./classes/sun/rmi/server ./hotspot/import/jre/lib/amd64/server ./j2re-image/lib/amd64/server ./j2sdk-debug-image/fastdebug/jre/lib/amd64/server ./j2sdk-debug-image/fastdebug/sample/nio/server ./j2sdk-debug-image/fastdebug/sample/webservices/EbayServer/src/ebay/server ./j2sdk-image/jre/lib/amd64/server ./j2sdk-image/sample/nio/server ./j2sdk-image/sample/webservices/EbayServer/src/ebay/server ./lib/amd64/server ./sample/nio/server ./sample/webservices/EbayServer/src/ebay/server ./symbols/META-INF/sym/rt.jar/java/rmi/server ./symbols/META-INF/sym/rt.jar/sun/rmi/server From Petr.Jiricka at Sun.COM Thu Dec 11 01:01:52 2008 From: Petr.Jiricka at Sun.COM (Petr Jiricka) Date: Thu, 11 Dec 2008 10:01:52 +0100 Subject: problem building openjdk on macos 10.5.5 In-Reply-To: References: Message-ID: <7E6717B7-E319-49BE-984F-9DC1741CF30B@sun.com> BTW, would it be possible to just publish a binary build once in a while? Preferably also for Mac OS 10.4. This would allow many more eyes to look at it and test it. Petr On Dec 11, 2008, at 1:32 AM, Stephen Bannasch wrote: > I'm getting this error: > > ld: library not found for -ljvm > collect2: ld returned 1 exit status > > This is on MacOS X 10.5.5, (core 2 duo) using soylatte to build. > > Here's a bunch more detail including the build output echoed to the > shell: > > http://pastie.org/336305 > > Here's just the end of the build output where the error occurs. > > Rebuilding > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/ > libioser12.so > because of > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/ > com.sun.corba.se.internal.io/ioser12/obj/.files_compiled > mapfile-vers > /usr/bin/gcc -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused > -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -mstackrealign -Di586 -DARCH='"i586"' -D_ALLBSD_SOURCE > -DRELEASE='"1.7.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE > -D_REENTRANT -I. > -I/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/ > com.sun.corba.se.internal.io/ioser12/CClassHeaders > -I../../../../src/solaris/javavm/export > -I../../../../src/share/javavm/export > -I../../../../src/share/javavm/include > -I../../../../src/solaris/javavm/include -ICClassHeaders > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/include > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/ > include/darwin > -I../../../../src/share/native/common > -I../../../../src/solaris/native/common > -I../../../../src/share/native/com/sun/corba/se/internal/io > -I../../../../src/solaris/native/com/sun/corba/se/internal/io > -L/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386 > -dynamiclib -o > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/ > libioser12.so > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/ > com.sun.corba.se.internal.io/ioser12/obj/ioser.o > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/ > lib/i386/server > -ljvm > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/ > lib/i386 > -ljava > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/ > lib/i386/server > -ljvm > ld: library not found for -ljvm > collect2: ld returned 1 exit status > From mvfranz at gmail.com Thu Dec 11 04:27:45 2008 From: mvfranz at gmail.com (Michael Franz) Date: Thu, 11 Dec 2008 07:27:45 -0500 Subject: problem building openjdk on macos 10.5.5 In-Reply-To: <7E6717B7-E319-49BE-984F-9DC1741CF30B@sun.com> References: <7E6717B7-E319-49BE-984F-9DC1741CF30B@sun.com> Message-ID: Petr, This is already a couple months old, but I have been using this to build the OS X version of the OpenJDK. http://landonf.bikemonkey.org/code/java/OpenJDK_7_Binaries.20080820.html I have never use Soylatte. The last time I was able to build was a pull from November 24, 2008. Some merges occurred after related to the hotspot that have prevent me from building. It would be nice to have binary updates on a regular basis, not sure who would do that. Michael On Thu, Dec 11, 2008 at 4:01 AM, Petr Jiricka wrote: > BTW, would it be possible to just publish a binary build once in a > while? Preferably also for Mac OS 10.4. This would allow many more > eyes to look at it and test it. > > Petr > > On Dec 11, 2008, at 1:32 AM, Stephen Bannasch wrote: > > > I'm getting this error: > > > > ld: library not found for -ljvm > > collect2: ld returned 1 exit status > > > > This is on MacOS X 10.5.5, (core 2 duo) using soylatte to build. > > > > Here's a bunch more detail including the build output echoed to the > > shell: > > > > http://pastie.org/336305 > > > > Here's just the end of the build output where the error occurs. > > > > Rebuilding > > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/ > > libioser12.so > > because of > > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/ > > com.sun.corba.se.internal.io/ioser12/obj/.files_compiled > > mapfile-vers > > /usr/bin/gcc -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused > > -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN > > -mstackrealign -Di586 -DARCH='"i586"' -D_ALLBSD_SOURCE > > -DRELEASE='"1.7.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE > > -D_REENTRANT -I. > > -I/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/ > > com.sun.corba.se.internal.io/ioser12/CClassHeaders > > -I../../../../src/solaris/javavm/export > > -I../../../../src/share/javavm/export > > -I../../../../src/share/javavm/include > > -I../../../../src/solaris/javavm/include -ICClassHeaders > > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/include > > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/ > > include/darwin > > -I../../../../src/share/native/common > > -I../../../../src/solaris/native/common > > -I../../../../src/share/native/com/sun/corba/se/internal/io > > -I../../../../src/solaris/native/com/sun/corba/se/internal/io > > -L/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386 > > -dynamiclib -o > > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/ > > libioser12.so > > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/ > > com.sun.corba.se.internal.io/ioser12/obj/ioser.o > > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/ > > lib/i386/server > > -ljvm > > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/ > > lib/i386 > > -ljava > > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/ > > lib/i386/server > > -ljvm > > ld: library not found for -ljvm > > collect2: ld returned 1 exit status > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081211/0f85ff9b/attachment.html From Kelly.Ohair at Sun.COM Thu Dec 11 08:08:02 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 11 Dec 2008 08:08:02 -0800 Subject: problem building openjdk on macos 10.5.5 In-Reply-To: References: <49406C2B.6090807@sun.com> Message-ID: <49413AE2.5090102@sun.com> The fact that you have both the pattern "amd64" and "i386" in the pathname is suspect. But I am not familiar with the way soylatte builds. Maybe this is some kind of ARCH setting problem? With a control build, hotspot is built first, which should end up in something like ./hotspot/import/jre/lib/amd64/server for a 64bit build, since you have that I assume you are doing a 64bit build. (Each server directory I'm talking about should have a libjvm.so in it) From there the jdk/make/java/redist makefile will copy libjvm.so to ./lib/amd64/server so that the build directory can actually be run for building demos. Lastly, the jdk images creation will then copy it to ./j2sdk-image/jre/lib/amd64/server. Solaris and Linux builds are different with regards to 32bit and 64bit and I'm not sure what pattern MacOSx soylatte builds has followed. -kto Stephen Bannasch wrote: > At 5:26 PM -0800 12/10/08, Kelly O'Hair wrote: >> Does >> >> /Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386/server >> >> >> contain a libjvm.so? > > I don't have a jre dir: > > $ ls -l /Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/ > total 40 > drwxr-xr-x 40 stephen staff 1360 Mar 25 2008 bin > lrwxr-xr-x 1 root staff 60 Jun 28 22:13 bsd-amd64 -> > /Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64 > drwxr-xr-x 2 stephen staff 68 Mar 25 2008 bundles > drwxr-xr-x 9 stephen staff 306 Mar 25 2008 classes > drwxr-xr-x 9 stephen staff 306 Mar 25 2008 demo > drwxr-xr-x 7 stephen staff 238 Mar 25 2008 gensrc > drwxr-xr-x 4 stephen staff 136 Mar 25 2008 hotspot > drwxr-xr-x 8 stephen staff 272 Mar 25 2008 include > drwxr-xr-x 9 stephen staff 306 Mar 25 2008 j2re-image > drwxr-xr-x 3 stephen staff 102 Mar 25 2008 j2sdk-debug-image > drwxr-xr-x 15 stephen staff 510 Mar 25 2008 j2sdk-image > drwxr-xr-x 2 stephen staff 68 Mar 25 2008 java.net > drwxr-xr-x 34 stephen staff 1156 Mar 25 2008 lib > drwxr-xr-x 4 stephen staff 136 Mar 25 2008 pack > drwxr-xr-x 8 stephen staff 272 Mar 25 2008 sample > -rw-r--r-- 1 stephen staff 10713 Mar 25 2008 sanityCheckMessages.txt > -rw-r--r-- 1 stephen staff 946 Mar 25 2008 sanityCheckWarnings.txt > drwxr-xr-x 2 stephen staff 68 Mar 25 2008 source-bundles > drwxr-xr-x 3 stephen staff 102 Mar 25 2008 symbols > drwxr-xr-x 54 stephen staff 1836 Mar 25 2008 tmp > > > And there are server files in these directories: > > [bsd-amd64]$ cd > /Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/ > > [bsd-amd64]$ find . -name server > ./classes/com/sun/tools/hat/internal/server > ./classes/com/sun/xml/internal/ws/encoding/soap/server > ./classes/com/sun/xml/internal/ws/protocol/soap/server > ./classes/com/sun/xml/internal/ws/protocol/xml/server > ./classes/com/sun/xml/internal/ws/server > ./classes/com/sun/xml/internal/ws/transport/http/server > ./classes/com/sun/xml/internal/ws/transport/local/server > ./classes/java/rmi/server > ./classes/sun/rmi/server > ./hotspot/import/jre/lib/amd64/server > ./j2re-image/lib/amd64/server > ./j2sdk-debug-image/fastdebug/jre/lib/amd64/server > ./j2sdk-debug-image/fastdebug/sample/nio/server > ./j2sdk-debug-image/fastdebug/sample/webservices/EbayServer/src/ebay/server > ./j2sdk-image/jre/lib/amd64/server > ./j2sdk-image/sample/nio/server > ./j2sdk-image/sample/webservices/EbayServer/src/ebay/server > ./lib/amd64/server > ./sample/nio/server > ./sample/webservices/EbayServer/src/ebay/server > ./symbols/META-INF/sym/rt.jar/java/rmi/server > ./symbols/META-INF/sym/rt.jar/sun/rmi/server > From glewis at eyesbeyond.com Sat Dec 13 08:04:50 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Sat, 13 Dec 2008 08:04:50 -0800 Subject: Dynamic invocation patches on OS X In-Reply-To: <38a53eb30812060443o6cadf4ddx4897e2ce7e2ccec9@mail.gmail.com> References: <38a53eb30812060443o6cadf4ddx4897e2ce7e2ccec9@mail.gmail.com> Message-ID: <20081213160450.GA47677@misty.eyesbeyond.com> G'day Ben, On Sat, Dec 06, 2008 at 12:43:47PM +0000, Ben Evans wrote: > There has been interest over on the mlvm-dev mailing list (for development > of a Java VM which had explicit Multi-Language support - including languages > with dynamic dispatch) in getting the dynamic invocation patches for OpenJDK > 7 running on OS X. > > Currently, the application of the patchset produced by John Rose (detailed > at http://wikis.sun.com/display/mlvm/Building) is failing on the bsd-port > code. Is there anyone on this list who could possibly spare some cycles to > help us understand where the patch failures are coming from - and even help > fix? > > I'm quite a newbie at a lot of OpenJDK - but I do have time to devote to > trying to fix this. Other people who would directly benefit from having a > working patchset include some of the core developers for JRuby - so this > would really help out some other projects as well. What errors are you seeing? Currently there are general build errors on Mac OS X. I have some local changes that I've been using to try and get around them, but I'm getting stuck on the compiler not liking some of the assembler (which hasn't actually changed recently, so I'm not sure what the issue is with it). Sorry for the slow response. -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From glewis at eyesbeyond.com Sat Dec 13 08:13:55 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Sat, 13 Dec 2008 08:13:55 -0800 Subject: problem building openjdk on macos 10.5.5 In-Reply-To: References: Message-ID: <20081213161355.GB47677@misty.eyesbeyond.com> On Wed, Dec 10, 2008 at 07:32:11PM -0500, Stephen Bannasch wrote: > I'm getting this error: > > ld: library not found for -ljvm > collect2: ld returned 1 exit status > > This is on MacOS X 10.5.5, (core 2 duo) using soylatte to build. You grabbed the SoyLatte amd64 build. Please grab the i386 build instead or modify your build flags to build a 64bit JVM. I did this the first time I tried to build on Mac OS X recently. > Here's a bunch more detail including the build output echoed to the shell: > > http://pastie.org/336305 > > Here's just the end of the build output where the error occurs. > > Rebuilding > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/libioser12.so > because of > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/.files_compiled > mapfile-vers > /usr/bin/gcc -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused > -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN > -mstackrealign -Di586 -DARCH='"i586"' -D_ALLBSD_SOURCE > -DRELEASE='"1.7.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE > -D_REENTRANT -I. > -I/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/CClassHeaders > -I../../../../src/solaris/javavm/export > -I../../../../src/share/javavm/export > -I../../../../src/share/javavm/include > -I../../../../src/solaris/javavm/include -ICClassHeaders > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/include > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/include/darwin > -I../../../../src/share/native/common > -I../../../../src/solaris/native/common > -I../../../../src/share/native/com/sun/corba/se/internal/io > -I../../../../src/solaris/native/com/sun/corba/se/internal/io > -L/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386 > -dynamiclib -o > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/libioser12.so > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/com.sun.corba.se.internal.io/ioser12/obj/ioser.o > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386/server > -ljvm > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386 > -ljava > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/lib/i386/server > -ljvm > ld: library not found for -ljvm > collect2: ld returned 1 exit status -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From glewis at eyesbeyond.com Sat Dec 13 08:16:55 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Sat, 13 Dec 2008 08:16:55 -0800 Subject: problem building openjdk on macos 10.5.5 In-Reply-To: References: <7E6717B7-E319-49BE-984F-9DC1741CF30B@sun.com> Message-ID: <20081213161655.GC47677@misty.eyesbeyond.com> On Thu, Dec 11, 2008 at 07:27:45AM -0500, Michael Franz wrote: > Petr, > > This is already a couple months old, but I have been using this to build the > OS X version of the OpenJDK. > http://landonf.bikemonkey.org/code/java/OpenJDK_7_Binaries.20080820.html I > have never use Soylatte. That would work too :). > The last time I was able to build was a pull from November 24, 2008. Some > merges occurred after related to the hotspot that have prevent me from > building. Whats your build set up like? I did some local changes to get around the merge problems, but now the compile dies on some of the assembler in copy_bsd_i486.inline.hpp and that hasn't changed for quite some time. Do you normally build a 32 bit or 64 bit JVM? Any special flags, what compiler versions? > It would be nice to have binary updates on a regular basis, not sure who > would do that. > > Michael > > On Thu, Dec 11, 2008 at 4:01 AM, Petr Jiricka wrote: > > > BTW, would it be possible to just publish a binary build once in a > > while? Preferably also for Mac OS 10.4. This would allow many more > > eyes to look at it and test it. > > > > Petr > > > > On Dec 11, 2008, at 1:32 AM, Stephen Bannasch wrote: > > > > > I'm getting this error: > > > > > > ld: library not found for -ljvm > > > collect2: ld returned 1 exit status > > > > > > This is on MacOS X 10.5.5, (core 2 duo) using soylatte to build. > > > > > > Here's a bunch more detail including the build output echoed to the > > > shell: > > > > > > http://pastie.org/336305 > > > > > > Here's just the end of the build output where the error occurs. > > > > > > Rebuilding > > > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/ > > > libioser12.so > > > because of > > > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/ > > > com.sun.corba.se.internal.io/ioser12/obj/.files_compiled > > > mapfile-vers > > > /usr/bin/gcc -O2 -fno-strict-aliasing -fPIC -W -Wall -Wno-unused > > > -Wno-parentheses -fno-omit-frame-pointer -D_LITTLE_ENDIAN > > > -mstackrealign -Di586 -DARCH='"i586"' -D_ALLBSD_SOURCE > > > -DRELEASE='"1.7.0-internal"' -D_LARGEFILE64_SOURCE -D_GNU_SOURCE > > > -D_REENTRANT -I. > > > -I/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/ > > > com.sun.corba.se.internal.io/ioser12/CClassHeaders > > > -I../../../../src/solaris/javavm/export > > > -I../../../../src/share/javavm/export > > > -I../../../../src/share/javavm/include > > > -I../../../../src/solaris/javavm/include -ICClassHeaders > > > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/include > > > -I/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/ > > > include/darwin > > > -I../../../../src/share/native/common > > > -I../../../../src/solaris/native/common > > > -I../../../../src/share/native/com/sun/corba/se/internal/io > > > -I../../../../src/solaris/native/com/sun/corba/se/internal/io > > > -L/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386 > > > -dynamiclib -o > > > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/lib/i386/ > > > libioser12.so > > > /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/corba/tmp/sun/ > > > com.sun.corba.se.internal.io/ioser12/obj/ioser.o > > > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/ > > > lib/i386/server > > > -ljvm > > > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/ > > > lib/i386 > > > -ljava > > > -L/Users/stephen/dev/java/src/soylatte/control/build/bsd-amd64/jre/ > > > lib/i386/server > > > -ljvm > > > ld: library not found for -ljvm > > > collect2: ld returned 1 exit status > > > > > > > > > > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From benjamin.john.evans at googlemail.com Sat Dec 13 08:20:29 2008 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Sat, 13 Dec 2008 16:20:29 +0000 Subject: Dynamic invocation patches on OS X In-Reply-To: <20081213160450.GA47677@misty.eyesbeyond.com> References: <38a53eb30812060443o6cadf4ddx4897e2ce7e2ccec9@mail.gmail.com> <20081213160450.GA47677@misty.eyesbeyond.com> Message-ID: <38a53eb30812130820k77f4230ak597a58a12edccb97@mail.gmail.com> Hi Greg, On Sat, Dec 13, 2008 at 4:04 PM, Greg Lewis wrote: > G'day Ben, > > On Sat, Dec 06, 2008 at 12:43:47PM +0000, Ben Evans wrote: > > There has been interest over on the mlvm-dev mailing list (for > development > > of a Java VM which had explicit Multi-Language support - including > languages > > with dynamic dispatch) in getting the dynamic invocation patches for > OpenJDK > > 7 running on OS X. > > > > Currently, the application of the patchset produced by John Rose > (detailed > > at http://wikis.sun.com/display/mlvm/Building) is failing on the > bsd-port > > code. Is there anyone on this list who could possibly spare some cycles > to > > help us understand where the patch failures are coming from - and even > help > > fix? > > > > I'm quite a newbie at a lot of OpenJDK - but I do have time to devote to > > trying to fix this. Other people who would directly benefit from having a > > working patchset include some of the core developers for JRuby - so this > > would really help out some other projects as well. > > What errors are you seeing? Currently there are general build errors on > Mac OS X. I have some local changes that I've been using to try and get > around them, but I'm getting stuck on the compiler not liking some of the > assembler (which hasn't actually changed recently, so I'm not sure what > the issue is with it). I've dug into it a bit more, and I'm pretty sure it's actually the same as the general build problem around the size of intptr_t that was discussed a little while ago. Is that the same as the issue you're currently working on fixing? Sorry for the slow response. Not at all - thanks for getting back to me. Is there anything I can do to help? My assembler's not that great but I'm happy to have a pop. Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081213/eaab2385/attachment.html From mvfranz at gmail.com Sat Dec 13 09:04:12 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 13 Dec 2008 12:04:12 -0500 Subject: problem building openjdk on macos 10.5.5 In-Reply-To: <20081213161655.GC47677@misty.eyesbeyond.com> References: <7E6717B7-E319-49BE-984F-9DC1741CF30B@sun.com> <20081213161655.GC47677@misty.eyesbeyond.com> Message-ID: Greg, I am not sure how to answer, here is what I do: I followed landonf instructions for building - installed the binary plugins - using landonf's openjdk build (I did't want to download soylatte) - make using make \ PKG_PATH=/usr/local/jdk1.7.0 \ ALT_BOOTDIR=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820 \ ALT_JDK_IMPORT_PATH=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820 \ ALT_BINARY_PLUGS_PATH=/Users/mfranz/developer/openjdk-bsd/bin/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=8 This is on Leopard on a dual Quad core. For OpenJDK 7, I have given that a little bit of a rest. I looked at the assembler_x86.cpp, that is a problem I do not want to tackle at this point. I have been looking at IcedTea6 again, that does not have the merged in code (also doesn't have the BSD changes). I have not been able to get hotspot to compile yet... Maybe I will take another look at the OpenJDK issue ... On Sat, Dec 13, 2008 at 11:16 AM, Greg Lewis wrote: > > The last time I was able to build was a pull from November 24, 2008. > Some > > merges occurred after related to the hotspot that have prevent me from > > building. > > Whats your build set up like? I did some local changes to get around the > merge problems, but now the compile dies on some of the assembler in > > copy_bsd_i486.inline.hpp > > and that hasn't changed for quite some time. > > Do you normally build a 32 bit or 64 bit JVM? Any special flags, what > compiler versions? > > > It would be nice to have binary updates on a regular basis, not sure who > > would do that. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081213/55590684/attachment.html From mvfranz at gmail.com Sat Dec 13 17:42:37 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 13 Dec 2008 20:42:37 -0500 Subject: Building Latest Repo On OS X - Taking a very long time! Message-ID: Hi, I have been able to get the latest repo to build again on OS X, however, it is taking at least 4 times longer than before. Was something added to the build that gets it into an endless loop? Was the previous build not building everything? How can I build less so that it does not take over 1 hour to build (it used to take less than 20 minutes). Actually, a build has not finished, so I don't really know how long it takes, I am beginning to thin it is in a recursive loop. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081213/fc24e952/attachment.html From mvfranz at gmail.com Sat Dec 13 18:34:02 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 13 Dec 2008 21:34:02 -0500 Subject: _LP64, int32_t and intptr_t Message-ID: Hi, Looking at assembler_x86.hpp and the usage of _LP64. It seems that _LP64 is used to decide whether or not to define 32 bit version of void movptr(Address dst, int32_t imm32); void movptr(Register dst, int32_t imm32); to work around casting calls when imm32 would be zero or NULL on 64 bit platforms. Wouldn't it be better to use the NOT_LP64 and LP64_ONLY macros with void MacroAssembler::movptr(Address dst, intptr_t src) void MacroAssembler::movptr(Register dst, intptr_t src) instead? This would change the casting to use the intptr_t instead of int32_t. This would allow the compiler to pick the correct method and reduce the need for 32 bit only versions. The the implementation would be: void MacroAssembler::movptr(Address dst, intptr_t src) { #ifdef _LP64 mov64(rscratch1, src); movq(dst, rscratch1); #else movslq(dst, src); #endif } void MacroAssembler::movptr(Register dst, intptr_t src) { LP64_ONLY(mov64(dst, src)) NOT_LP64(movl(dst, src)); } would not need to be changed as it already uses the LP64 macros. What is interesting that void MacroAssembler::movptr(Register dst, int32_t src) { mov64(dst, (intptr_t)src); } uses mov64 instead of movl. I have attached the changes I did to get the OS X build to work again. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081213/9b7550d6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: hotspot.patches Type: application/octet-stream Size: 21340 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081213/9b7550d6/attachment.obj From mvfranz at gmail.com Sat Dec 13 21:44:18 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 14 Dec 2008 00:44:18 -0500 Subject: Building Latest Repo On OS X - Taking a very long time! In-Reply-To: References: Message-ID: This must have been a freak of nature, it is back to taking only about 35 minutes. On Sat, Dec 13, 2008 at 8:42 PM, Michael Franz wrote: > Hi, > > I have been able to get the latest repo to build again on OS X, however, it > is taking at least 4 times longer than before. Was something added to the > build that gets it into an endless loop? Was the previous build not > building everything? How can I build less so that it does not take over 1 > hour to build (it used to take less than 20 minutes). Actually, a build has > not finished, so I don't really know how long it takes, I am beginning to > thin it is in a recursive loop. > > Michael > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081214/16031b9b/attachment.html From mvfranz at gmail.com Sun Dec 14 16:38:58 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 14 Dec 2008 19:38:58 -0500 Subject: Dynamic invocation patches on OS X In-Reply-To: <38a53eb30812130820k77f4230ak597a58a12edccb97@mail.gmail.com> References: <38a53eb30812060443o6cadf4ddx4897e2ce7e2ccec9@mail.gmail.com> <20081213160450.GA47677@misty.eyesbeyond.com> <38a53eb30812130820k77f4230ak597a58a12edccb97@mail.gmail.com> Message-ID: Ben, I was able to follow the instructions to apply the patches and build. How do I test that the JDK is working with the new functionality? Michael On Sat, Dec 13, 2008 at 11:20 AM, Ben Evans < benjamin.john.evans at googlemail.com> wrote: > Hi Greg, > > On Sat, Dec 13, 2008 at 4:04 PM, Greg Lewis wrote: > >> G'day Ben, >> >> On Sat, Dec 06, 2008 at 12:43:47PM +0000, Ben Evans wrote: >> > There has been interest over on the mlvm-dev mailing list (for >> development >> > of a Java VM which had explicit Multi-Language support - including >> languages >> > with dynamic dispatch) in getting the dynamic invocation patches for >> OpenJDK >> > 7 running on OS X. >> > >> > Currently, the application of the patchset produced by John Rose >> (detailed >> > at http://wikis.sun.com/display/mlvm/Building) is failing on the >> bsd-port >> > code. Is there anyone on this list who could possibly spare some cycles >> to >> > help us understand where the patch failures are coming from - and even >> help >> > fix? >> > >> > I'm quite a newbie at a lot of OpenJDK - but I do have time to devote to >> > trying to fix this. Other people who would directly benefit from having >> a >> > working patchset include some of the core developers for JRuby - so this >> > would really help out some other projects as well. >> >> What errors are you seeing? Currently there are general build errors on >> Mac OS X. I have some local changes that I've been using to try and get >> around them, but I'm getting stuck on the compiler not liking some of the >> assembler (which hasn't actually changed recently, so I'm not sure what >> the issue is with it). > > > I've dug into it a bit more, and I'm pretty sure it's actually the same as > the general build problem around the size of intptr_t that was discussed a > little while ago. Is that the same as the issue you're currently working on > fixing? > > Sorry for the slow response. > > > Not at all - thanks for getting back to me. Is there anything I can do to > help? My assembler's not that great but I'm happy to have a pop. > > Ben > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081214/f77b55c8/attachment.html From benjamin.john.evans at googlemail.com Mon Dec 15 00:35:23 2008 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Mon, 15 Dec 2008 08:35:23 +0000 Subject: Dynamic invocation patches on OS X In-Reply-To: <38a53eb30812150031s19d7eba1s9967cdf92864491d@mail.gmail.com> References: <38a53eb30812060443o6cadf4ddx4897e2ce7e2ccec9@mail.gmail.com> <20081213160450.GA47677@misty.eyesbeyond.com> <38a53eb30812130820k77f4230ak597a58a12edccb97@mail.gmail.com> <38a53eb30812150031s19d7eba1s9967cdf92864491d@mail.gmail.com> Message-ID: <38a53eb30812150035i458c723as6fac06e5ec028b18@mail.gmail.com> Forgot to keep the group on the reply, my bad. ---------- Forwarded message ---------- From: Ben Evans Date: Mon, Dec 15, 2008 at 8:31 AM Subject: Re: Dynamic invocation patches on OS X To: Michael Franz Hi Michael, On Mon, Dec 15, 2008 at 12:38 AM, Michael Franz wrote: > Ben, > > I was able to follow the instructions to apply the patches and build. How > do I test that the JDK is working with the new functionality? > One of the new core classes which should be present now is java.dyn.MethodHandle Try a simple import of that class - I think it ends up residing in rt.jar I'll update from repo and reapply the patches and try to confirm. Out of interest, what changed in the repo to fix the problems people were seeing earlier? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081215/f7814bcd/attachment.html From benjamin.john.evans at googlemail.com Mon Dec 15 01:14:48 2008 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Mon, 15 Dec 2008 09:14:48 +0000 Subject: Building Latest Repo On OS X - Taking a very long time! In-Reply-To: References: Message-ID: <38a53eb30812150114n42c9c1b8o981b89bda29b2884@mail.gmail.com> Hi Michael, On Sun, Dec 14, 2008 at 5:44 AM, Michael Franz wrote: > This must have been a freak of nature, it is back to taking only about 35 > minutes. I can't get the latest repo to build (nb this is without applying any patches). It fails after about 4 minutes on this: /Users/boxcat/projects/jdk7-b40-bsd-clean/sources/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp: In member function 'void InterpreterMacroAssembler::empty_expression_stack()': /Users/boxcat/projects/jdk7-b40-bsd-clean/sources/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:123: error: call of overloaded 'movptr(Address, int)' is ambiguous /Users/boxcat/projects/jdk7-b40-bsd-clean/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2010: note: candidates are: void MacroAssembler::movptr(Address, intptr_t) /Users/boxcat/projects/jdk7-b40-bsd-clean/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2012: note: void MacroAssembler::movptr(Address, RegisterImpl*) make[6]: *** [incls/_precompiled.incl.gch] Error 1 make[5]: *** [the_vm] Error 2 make[4]: *** [product] Error 2 make[3]: *** [generic_build2] Error 2 make[2]: *** [product] Error 2 make[1]: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2 CatBasket:sources boxcat$ My build machine is 10.5.5, 2 x Dual-Core Xeon. Is your build still working with the latest repo? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081215/0c7b0f03/attachment.html From mvfranz at gmail.com Mon Dec 15 04:32:38 2008 From: mvfranz at gmail.com (Michael Franz) Date: Mon, 15 Dec 2008 07:32:38 -0500 Subject: Building Latest Repo On OS X - Taking a very long time! In-Reply-To: <38a53eb30812150114n42c9c1b8o981b89bda29b2884@mail.gmail.com> References: <38a53eb30812150114n42c9c1b8o981b89bda29b2884@mail.gmail.com> Message-ID: Ben, I am building the latest repo, but I made changes. I sent the patch to the list with the subject of '_LP64, int32_t and intptr_t' since that is what the issue is with the build. I am not sure if this breaks other platforms and someone will have to test. MIchael On Mon, Dec 15, 2008 at 4:14 AM, Ben Evans < benjamin.john.evans at googlemail.com> wrote: > Hi Michael, > > On Sun, Dec 14, 2008 at 5:44 AM, Michael Franz wrote: > >> This must have been a freak of nature, it is back to taking only about 35 >> minutes. > > > I can't get the latest repo to build (nb this is without applying any > patches). It fails after about 4 minutes on this: > > /Users/boxcat/projects/jdk7-b40-bsd-clean/sources/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp: > In member function 'void > InterpreterMacroAssembler::empty_expression_stack()': > /Users/boxcat/projects/jdk7-b40-bsd-clean/sources/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:123: > error: call of overloaded 'movptr(Address, int)' is ambiguous > /Users/boxcat/projects/jdk7-b40-bsd-clean/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2010: > note: candidates are: void MacroAssembler::movptr(Address, intptr_t) > /Users/boxcat/projects/jdk7-b40-bsd-clean/sources/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2012: > note: void MacroAssembler::movptr(Address, RegisterImpl*) > make[6]: *** [incls/_precompiled.incl.gch] Error 1 > make[5]: *** [the_vm] Error 2 > make[4]: *** [product] Error 2 > make[3]: *** [generic_build2] Error 2 > make[2]: *** [product] Error 2 > make[1]: *** [hotspot-build] Error 2 > make: *** [build_product_image] Error 2 > CatBasket:sources boxcat$ > > My build machine is 10.5.5, 2 x Dual-Core Xeon. > > Is your build still working with the latest repo? > > Thanks, > > Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081215/dad639c3/attachment.html From Xiaobin.Lu at Sun.COM Mon Dec 15 16:27:25 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 15 Dec 2008 16:27:25 -0800 Subject: Build hotspot on Mac Message-ID: <4946F5ED.406@Sun.COM> Hi folks, I just got my Mac setup and would like to build hotspot on it. Would someone point me the link about where to get the source to build? Also any link to the documentation would be helpful too. Thanks, -Xiaobin From mvfranz at gmail.com Mon Dec 15 16:39:21 2008 From: mvfranz at gmail.com (Michael Franz) Date: Mon, 15 Dec 2008 19:39:21 -0500 Subject: Build hotspot on Mac In-Reply-To: <4946F5ED.406@Sun.COM> References: <4946F5ED.406@Sun.COM> Message-ID: Xiaobin, Everything I follow is from here: http://landonf.bikemonkey.org/code/java/SoyLatte_Meets_OpenJDK.20080819.html I replaced Soylatte with this build of the OpenJDK http://landonf.bikemonkey.org/code/java/OpenJDK_7_Binaries.20080820.html Michael On Mon, Dec 15, 2008 at 7:27 PM, Xiaobin Lu wrote: > Hi folks, > > I just got my Mac setup and would like to build hotspot on it. Would > someone point me the link about where to get the source to build? Also > any link to the documentation would be helpful too. > > Thanks, > -Xiaobin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081215/7ce164e5/attachment.html From mvfranz at gmail.com Mon Dec 15 16:46:36 2008 From: mvfranz at gmail.com (Michael Franz) Date: Mon, 15 Dec 2008 19:46:36 -0500 Subject: Dynamic invocation patches on OS X In-Reply-To: <38a53eb30812150035i458c723as6fac06e5ec028b18@mail.gmail.com> References: <38a53eb30812060443o6cadf4ddx4897e2ce7e2ccec9@mail.gmail.com> <20081213160450.GA47677@misty.eyesbeyond.com> <38a53eb30812130820k77f4230ak597a58a12edccb97@mail.gmail.com> <38a53eb30812150031s19d7eba1s9967cdf92864491d@mail.gmail.com> <38a53eb30812150035i458c723as6fac06e5ec028b18@mail.gmail.com> Message-ID: Guess I didn't apply the patches correctly. I don't have any class that contains MethodHandle in its name and there is no java.dyn package On Mon, Dec 15, 2008 at 3:35 AM, Ben Evans < benjamin.john.evans at googlemail.com> wrote: > Forgot to keep the group on the reply, my bad. > > > ---------- Forwarded message ---------- > From: Ben Evans > Date: Mon, Dec 15, 2008 at 8:31 AM > Subject: Re: Dynamic invocation patches on OS X > To: Michael Franz > > > Hi Michael, > > On Mon, Dec 15, 2008 at 12:38 AM, Michael Franz wrote: > >> Ben, >> >> I was able to follow the instructions to apply the patches and build. How >> do I test that the JDK is working with the new functionality? >> > > One of the new core classes which should be present now is > java.dyn.MethodHandle > > Try a simple import of that class - I think it ends up residing in rt.jar > > I'll update from repo and reapply the patches and try to confirm. > > Out of interest, what changed in the repo to fix the problems people were > seeing earlier? > > Thanks, > > Ben > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081215/225bbfde/attachment.html From benjamin.john.evans at googlemail.com Tue Dec 16 05:56:23 2008 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Tue, 16 Dec 2008 13:56:23 +0000 Subject: _LP64, int32_t and intptr_t In-Reply-To: References: Message-ID: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> Hi Michael, On Sun, Dec 14, 2008 at 2:34 AM, Michael Franz wrote: > Hi, > > I have attached the changes I did to get the OS X build to work again. I've applied the patch via: patch -p1 < hotspot.patches in the hotspot directory and am building via: make ALT_JDK_IMPORT_PATH=/usr/local/soylatte16-i386-1.0.3 ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 ALT_BINARY_PLUGS_PATH=$HOME/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 but the build fails after about 20 minutes with this error message: >>>Recursively making tracing all @ Tue 16 Dec 2008 13:49:35 GMT ... # Java sources to be compiled: (listed in file /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/tmp/sun/sun.tracing/.classes.list) ../../../src/share/classes/sun/tracing/MultiplexProviderFactory.java ../../../src/share/classes/sun/tracing/NullProviderFactory.java ../../../src/share/classes/sun/tracing/PrintStreamProviderFactory.java ../../../src/share/classes/sun/tracing/ProbeSkeleton.java ../../../src/share/classes/sun/tracing/ProviderSkeleton.java ../../../src/share/classes/sun/tracing/dtrace/Activation.java ../../../src/share/classes/sun/tracing/dtrace/DTraceProbe.java ../../../src/share/classes/sun/tracing/dtrace/DTraceProvider.java ../../../src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java ../../../src/share/classes/sun/tracing/dtrace/JVM.java ../../../src/share/classes/sun/tracing/package-info.java # Running javac: /usr/local/soylatte16-i386-1.0.3/bin/javac -J-XX:ThreadStackSize=768 -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -source 1.5 -target 5 -encoding ascii -Xbootclasspath:/Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/classes -sourcepath /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes -d /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/classes @/Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/tmp/sun/sun.tracing/.classes.list.filtered ../../../src/share/classes/sun/tracing/MultiplexProviderFactory.java:75: type parameters of T cannot be determined; no unique maximal instance exists for type variable T with upper bounds T,com.sun.tracing.Provider return provider.newProxyInstance(); ^ ../../../src/share/classes/sun/tracing/NullProviderFactory.java:63: type parameters of T cannot be determined; no unique maximal instance exists for type variable T with upper bounds T,com.sun.tracing.Provider return provider.newProxyInstance(); ^ ../../../src/share/classes/sun/tracing/PrintStreamProviderFactory.java:64: type parameters of T cannot be determined; no unique maximal instance exists for type variable T with upper bounds T,com.sun.tracing.Provider return provider.newProxyInstance(); ^ ../../../src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java:81: type parameters of T cannot be determined; no unique maximal instance exists for type variable T with upper bounds T,com.sun.tracing.Provider T proxy = jsdt.newProxyInstance(); ^ 4 errors make[4]: *** [.compile.classlist] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 This is just with the current repo - I havcen't applied the invokedynamic patches yet. I'm going to carry on investigating - but any ideas? (This is OS X 10.5.5 on a 2 CPU dual-core Xeon Mac Pro) Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081216/0dc6752b/attachment.html From mvfranz at gmail.com Tue Dec 16 08:05:31 2008 From: mvfranz at gmail.com (Michael Franz) Date: Tue, 16 Dec 2008 11:05:31 -0500 Subject: _LP64, int32_t and intptr_t In-Reply-To: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> Message-ID: Ben, I have not built the latest repo, I was working on one from 13/14. There may have been merges done after I did my pull. These errors are in Java code and are unrelated to the patches. Further evidence that the repo has changed since my last build. I will not be able to look at this until tonight. If you can, pull a different revision and try again. Michael On 12/16/08, Ben Evans wrote: > Hi Michael, > > On Sun, Dec 14, 2008 at 2:34 AM, Michael Franz wrote: > >> Hi, >> >> I have attached the changes I did to get the OS X build to work again. > > > I've applied the patch via: patch -p1 < hotspot.patches in the hotspot > directory and am building via: > > make ALT_JDK_IMPORT_PATH=/usr/local/soylatte16-i386-1.0.3 > ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 > ALT_BINARY_PLUGS_PATH=$HOME/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 > > but the build fails after about 20 minutes with this error message: > >>>>Recursively making tracing all @ Tue 16 Dec 2008 13:49:35 GMT ... > # Java sources to be compiled: (listed in file > /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/tmp/sun/sun.tracing/.classes.list) > ../../../src/share/classes/sun/tracing/MultiplexProviderFactory.java > ../../../src/share/classes/sun/tracing/NullProviderFactory.java > ../../../src/share/classes/sun/tracing/PrintStreamProviderFactory.java > ../../../src/share/classes/sun/tracing/ProbeSkeleton.java > ../../../src/share/classes/sun/tracing/ProviderSkeleton.java > ../../../src/share/classes/sun/tracing/dtrace/Activation.java > ../../../src/share/classes/sun/tracing/dtrace/DTraceProbe.java > ../../../src/share/classes/sun/tracing/dtrace/DTraceProvider.java > ../../../src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java > ../../../src/share/classes/sun/tracing/dtrace/JVM.java > ../../../src/share/classes/sun/tracing/package-info.java > # Running javac: > /usr/local/soylatte16-i386-1.0.3/bin/javac -J-XX:ThreadStackSize=768 > -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m > -source 1.5 -target 5 -encoding ascii > -Xbootclasspath:/Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/classes > -sourcepath > /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes > -d /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/classes > @/Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/tmp/sun/sun.tracing/.classes.list.filtered > ../../../src/share/classes/sun/tracing/MultiplexProviderFactory.java:75: > type parameters of T cannot be determined; no unique maximal instance > exists for type variable T with upper bounds T,com.sun.tracing.Provider > return provider.newProxyInstance(); > ^ > ../../../src/share/classes/sun/tracing/NullProviderFactory.java:63: type > parameters of T cannot be determined; no unique maximal instance exists > for type variable T with upper bounds T,com.sun.tracing.Provider > return provider.newProxyInstance(); > ^ > ../../../src/share/classes/sun/tracing/PrintStreamProviderFactory.java:64: > type parameters of T cannot be determined; no unique maximal instance > exists for type variable T with upper bounds T,com.sun.tracing.Provider > return provider.newProxyInstance(); > ^ > ../../../src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java:81: > type parameters of T cannot be determined; no unique maximal instance > exists for type variable T with upper bounds T,com.sun.tracing.Provider > T proxy = jsdt.newProxyInstance(); > ^ > 4 errors > make[4]: *** [.compile.classlist] Error 1 > make[3]: *** [all] Error 1 > make[2]: *** [all] Error 1 > make[1]: *** [jdk-build] Error 2 > make: *** [build_product_image] Error 2 > > This is just with the current repo - I havcen't applied the invokedynamic > patches yet. > > I'm going to carry on investigating - but any ideas? > > (This is OS X 10.5.5 on a 2 CPU dual-core Xeon Mac Pro) > > Thanks, > > Ben > -- Sent from Gmail for mobile | mobile.google.com From glewis at eyesbeyond.com Tue Dec 16 08:59:54 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Tue, 16 Dec 2008 08:59:54 -0800 Subject: _LP64, int32_t and intptr_t In-Reply-To: References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> Message-ID: <20081216165954.GA2893@misty.eyesbeyond.com> On Tue, Dec 16, 2008 at 11:05:31AM -0500, Michael Franz wrote: > I have not built the latest repo, I was working on one from 13/14. > There may have been merges done after I did my pull. > > These errors are in Java code and are unrelated to the patches. > Further evidence that the repo has changed since my last build. > > I will not be able to look at this until tonight. If you can, pull a > different revision and try again. All commits to the repository are sent to this list as far as I can tell. I certainly haven't committed any changes since the merge in late November that introduced the problem in HotSpot. I have some local hacks (different from Michael's) to try and get around that, but I'm seeing other errors that look like they are due to the version of as on my Mac. We are pretty due to do some more merging, but I'm hoping our friends at Sun (hi Xiaobin!) can maybe come up with an acceptable change they are willing to commit to the main repo to fix the HotSpot compile problems. Ben, it might be worth trying to bootstrap with the version of OpenJDK that is available in binary form on Landon Fuller's pages. That is what Michael uses. If I can get a build going I'd be happy to cut a newer binary and put it up for download. > Michael > > > > On 12/16/08, Ben Evans wrote: > > Hi Michael, > > > > On Sun, Dec 14, 2008 at 2:34 AM, Michael Franz wrote: > > > >> Hi, > >> > >> I have attached the changes I did to get the OS X build to work again. > > > > > > I've applied the patch via: patch -p1 < hotspot.patches in the hotspot > > directory and am building via: > > > > make ALT_JDK_IMPORT_PATH=/usr/local/soylatte16-i386-1.0.3 > > ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 > > ALT_BINARY_PLUGS_PATH=$HOME/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 > > > > but the build fails after about 20 minutes with this error message: > > > >>>>Recursively making tracing all @ Tue 16 Dec 2008 13:49:35 GMT ... > > # Java sources to be compiled: (listed in file > > /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/tmp/sun/sun.tracing/.classes.list) > > ../../../src/share/classes/sun/tracing/MultiplexProviderFactory.java > > ../../../src/share/classes/sun/tracing/NullProviderFactory.java > > ../../../src/share/classes/sun/tracing/PrintStreamProviderFactory.java > > ../../../src/share/classes/sun/tracing/ProbeSkeleton.java > > ../../../src/share/classes/sun/tracing/ProviderSkeleton.java > > ../../../src/share/classes/sun/tracing/dtrace/Activation.java > > ../../../src/share/classes/sun/tracing/dtrace/DTraceProbe.java > > ../../../src/share/classes/sun/tracing/dtrace/DTraceProvider.java > > ../../../src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java > > ../../../src/share/classes/sun/tracing/dtrace/JVM.java > > ../../../src/share/classes/sun/tracing/package-info.java > > # Running javac: > > /usr/local/soylatte16-i386-1.0.3/bin/javac -J-XX:ThreadStackSize=768 > > -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m > > -source 1.5 -target 5 -encoding ascii > > -Xbootclasspath:/Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/classes > > -sourcepath > > /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes > > -d /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/classes > > @/Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/tmp/sun/sun.tracing/.classes.list.filtered > > ../../../src/share/classes/sun/tracing/MultiplexProviderFactory.java:75: > > type parameters of T cannot be determined; no unique maximal instance > > exists for type variable T with upper bounds T,com.sun.tracing.Provider > > return provider.newProxyInstance(); > > ^ > > ../../../src/share/classes/sun/tracing/NullProviderFactory.java:63: type > > parameters of T cannot be determined; no unique maximal instance exists > > for type variable T with upper bounds T,com.sun.tracing.Provider > > return provider.newProxyInstance(); > > ^ > > ../../../src/share/classes/sun/tracing/PrintStreamProviderFactory.java:64: > > type parameters of T cannot be determined; no unique maximal instance > > exists for type variable T with upper bounds T,com.sun.tracing.Provider > > return provider.newProxyInstance(); > > ^ > > ../../../src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java:81: > > type parameters of T cannot be determined; no unique maximal instance > > exists for type variable T with upper bounds T,com.sun.tracing.Provider > > T proxy = jsdt.newProxyInstance(); > > ^ > > 4 errors > > make[4]: *** [.compile.classlist] Error 1 > > make[3]: *** [all] Error 1 > > make[2]: *** [all] Error 1 > > make[1]: *** [jdk-build] Error 2 > > make: *** [build_product_image] Error 2 > > > > This is just with the current repo - I havcen't applied the invokedynamic > > patches yet. > > > > I'm going to carry on investigating - but any ideas? > > > > (This is OS X 10.5.5 on a 2 CPU dual-core Xeon Mac Pro) > > > > Thanks, > > > > Ben > > > > -- > Sent from Gmail for mobile | mobile.google.com -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From Xiaobin.Lu at Sun.COM Tue Dec 16 11:14:58 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 16 Dec 2008 11:14:58 -0800 Subject: _LP64, int32_t and intptr_t In-Reply-To: <20081216165954.GA2893@misty.eyesbeyond.com> References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> Message-ID: <4947FE32.1050802@Sun.COM> Greg Lewis wrote: > On Tue, Dec 16, 2008 at 11:05:31AM -0500, Michael Franz wrote: > >> I have not built the latest repo, I was working on one from 13/14. >> There may have been merges done after I did my pull. >> >> These errors are in Java code and are unrelated to the patches. >> Further evidence that the repo has changed since my last build. >> >> I will not be able to look at this until tonight. If you can, pull a >> different revision and try again. >> > > All commits to the repository are sent to this list as far as I can tell. > I certainly haven't committed any changes since the merge in late November > that introduced the problem in HotSpot. I have some local hacks (different > from Michael's) to try and get around that, but I'm seeing other errors > that look like they are due to the version of as on my Mac. > > We are pretty due to do some more merging, but I'm hoping our friends at > Sun (hi Xiaobin!) can maybe come up with an acceptable change they are > willing to commit to the main repo to fix the HotSpot compile problems. > Hi Greg, We are working on a more long term fix for this problem. But in the meantime, I think a better fix would be just change as few as possible so that in future we can back it out easily. -Xiaobin > Ben, it might be worth trying to bootstrap with the version of OpenJDK > that is available in binary form on Landon Fuller's pages. That is what > Michael uses. > > If I can get a build going I'd be happy to cut a newer binary and put > it up for download. > > >> Michael >> >> >> >> On 12/16/08, Ben Evans wrote: >> >>> Hi Michael, >>> >>> On Sun, Dec 14, 2008 at 2:34 AM, Michael Franz wrote: >>> >>> >>>> Hi, >>>> >>>> I have attached the changes I did to get the OS X build to work again. >>>> >>> I've applied the patch via: patch -p1 < hotspot.patches in the hotspot >>> directory and am building via: >>> >>> make ALT_JDK_IMPORT_PATH=/usr/local/soylatte16-i386-1.0.3 >>> ALT_BOOTDIR=/usr/local/soylatte16-i386-1.0.3 >>> ALT_BINARY_PLUGS_PATH=$HOME/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 >>> >>> but the build fails after about 20 minutes with this error message: >>> >>> >>>>>> Recursively making tracing all @ Tue 16 Dec 2008 13:49:35 GMT ... >>>>>> >>> # Java sources to be compiled: (listed in file >>> /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/tmp/sun/sun.tracing/.classes.list) >>> ../../../src/share/classes/sun/tracing/MultiplexProviderFactory.java >>> ../../../src/share/classes/sun/tracing/NullProviderFactory.java >>> ../../../src/share/classes/sun/tracing/PrintStreamProviderFactory.java >>> ../../../src/share/classes/sun/tracing/ProbeSkeleton.java >>> ../../../src/share/classes/sun/tracing/ProviderSkeleton.java >>> ../../../src/share/classes/sun/tracing/dtrace/Activation.java >>> ../../../src/share/classes/sun/tracing/dtrace/DTraceProbe.java >>> ../../../src/share/classes/sun/tracing/dtrace/DTraceProvider.java >>> ../../../src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java >>> ../../../src/share/classes/sun/tracing/dtrace/JVM.java >>> ../../../src/share/classes/sun/tracing/package-info.java >>> # Running javac: >>> /usr/local/soylatte16-i386-1.0.3/bin/javac -J-XX:ThreadStackSize=768 >>> -J-client -J-Xmx896m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m >>> -source 1.5 -target 5 -encoding ascii >>> -Xbootclasspath:/Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/classes >>> -sourcepath >>> /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/gensrc:../../../src/solaris/classes:../../../src/share/classes >>> -d /Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/classes >>> @/Users/boxcat/projects/jdk7-b40-bsd/sources/build/bsd-i586/tmp/sun/sun.tracing/.classes.list.filtered >>> ../../../src/share/classes/sun/tracing/MultiplexProviderFactory.java:75: >>> type parameters of T cannot be determined; no unique maximal instance >>> exists for type variable T with upper bounds T,com.sun.tracing.Provider >>> return provider.newProxyInstance(); >>> ^ >>> ../../../src/share/classes/sun/tracing/NullProviderFactory.java:63: type >>> parameters of T cannot be determined; no unique maximal instance exists >>> for type variable T with upper bounds T,com.sun.tracing.Provider >>> return provider.newProxyInstance(); >>> ^ >>> ../../../src/share/classes/sun/tracing/PrintStreamProviderFactory.java:64: >>> type parameters of T cannot be determined; no unique maximal instance >>> exists for type variable T with upper bounds T,com.sun.tracing.Provider >>> return provider.newProxyInstance(); >>> ^ >>> ../../../src/share/classes/sun/tracing/dtrace/DTraceProviderFactory.java:81: >>> type parameters of T cannot be determined; no unique maximal instance >>> exists for type variable T with upper bounds T,com.sun.tracing.Provider >>> T proxy = jsdt.newProxyInstance(); >>> ^ >>> 4 errors >>> make[4]: *** [.compile.classlist] Error 1 >>> make[3]: *** [all] Error 1 >>> make[2]: *** [all] Error 1 >>> make[1]: *** [jdk-build] Error 2 >>> make: *** [build_product_image] Error 2 >>> >>> This is just with the current repo - I havcen't applied the invokedynamic >>> patches yet. >>> >>> I'm going to carry on investigating - but any ideas? >>> >>> (This is OS X 10.5.5 on a 2 CPU dual-core Xeon Mac Pro) >>> >>> Thanks, >>> >>> Ben >>> >>> >> -- >> Sent from Gmail for mobile | mobile.google.com >> > > From benjamin.john.evans at googlemail.com Tue Dec 16 11:42:49 2008 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Tue, 16 Dec 2008 19:42:49 +0000 Subject: _LP64, int32_t and intptr_t In-Reply-To: <20081216165954.GA2893@misty.eyesbeyond.com> References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> Message-ID: <38a53eb30812161142g91bd92ckd33190f48b8da96b@mail.gmail.com> Hi Greg, On Tue, Dec 16, 2008 at 4:59 PM, Greg Lewis wrote: > On Tue, Dec 16, 2008 at 11:05:31AM -0500, Michael Franz wrote: > > I have not built the latest repo, I was working on one from 13/14. > > There may have been merges done after I did my pull. > > > > These errors are in Java code and are unrelated to the patches. > > Further evidence that the repo has changed since my last build. > > > > I will not be able to look at this until tonight. If you can, pull a > > different revision and try again. > > All commits to the repository are sent to this list as far as I can tell. > I certainly haven't committed any changes since the merge in late November > that introduced the problem in HotSpot. I have some local hacks (different > from Michael's) to try and get around that, but I'm seeing other errors > that look like they are due to the version of as on my Mac. > > We are pretty due to do some more merging, but I'm hoping our friends at > Sun (hi Xiaobin!) can maybe come up with an acceptable change they are > willing to commit to the main repo to fix the HotSpot compile problems. > > Ben, it might be worth trying to bootstrap with the version of OpenJDK > that is available in binary form on Landon Fuller's pages. That is what > Michael uses. Using the OpenJDK build on Landon's pages enables the patched build to complete, at least as far as the self-test error mentioned here: http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-September/000044.html As Karen suggests on that page, I've copied the .dylib's over a copy of the existing JDK build, so I think I have a working build now. I'm still struggling to get the invokedynamic patches applied, but that's another story. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081216/bdd62b8c/attachment.html From Xiaobin.Lu at Sun.COM Tue Dec 16 12:11:02 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 16 Dec 2008 12:11:02 -0800 Subject: forest.py for mac Message-ID: <49480B56.8050107@Sun.COM> Hi folks, Anyone could point me out how to get forest.py for Mac? Thanks in advance! -Xiaobin From benjamin.john.evans at googlemail.com Tue Dec 16 12:19:19 2008 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Tue, 16 Dec 2008 20:19:19 +0000 Subject: forest.py for mac In-Reply-To: <49480B56.8050107@Sun.COM> References: <49480B56.8050107@Sun.COM> Message-ID: <38a53eb30812161219g6870a99cy93d02cd111ace35b@mail.gmail.com> Hi Xiaobin, On Tue, Dec 16, 2008 at 8:11 PM, Xiaobin Lu wrote: > Hi folks, > > Anyone could point me out how to get forest.py for Mac? > > Thanks in advance! > -Xiaobin I did it the crude way: "1) Go to the public repository (http://hg.akoha.org/hgforest/), and click on the top link, then the 'files' link on the changeset description page, then the 'raw' link at the top and save it with the other extensions (/Library/Python/2.5/site-packages/hgext/ on a Mac) " I think there must be a way to do it using hg itself, but I couldn't figure out how. I have some of my build notes on my technical blog at: http://boxcatjunction.blogspot.com/ Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081216/f228fb79/attachment.html From paulp at improving.org Tue Dec 16 12:19:03 2008 From: paulp at improving.org (Paul Phillips) Date: Tue, 16 Dec 2008 12:19:03 -0800 Subject: forest.py for mac In-Reply-To: <49480B56.8050107@Sun.COM> References: <49480B56.8050107@Sun.COM> Message-ID: <20081216201903.GA64879@jon.local> On Tue, Dec 16, 2008 at 12:11:02PM -0800, Xiaobin Lu wrote: > Anyone could point me out how to get forest.py for Mac? hg clone http://hg.akoha.org/hgforest -- Paul Phillips | Appreciation is a wonderful thing; it makes what is Vivid | excellent in others belong to us as well. Empiricist | -- Voltaire i'll ship a pulp |----------* http://www.improving.org/paulp/ *---------- From mvfranz at gmail.com Tue Dec 16 14:47:13 2008 From: mvfranz at gmail.com (Michael Franz) Date: Tue, 16 Dec 2008 17:47:13 -0500 Subject: _LP64, int32_t and intptr_t In-Reply-To: <38a53eb30812161142g91bd92ckd33190f48b8da96b@mail.gmail.com> References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> <38a53eb30812161142g91bd92ckd33190f48b8da96b@mail.gmail.com> Message-ID: Ben, What I do for this is, delete the test_gamma from the bsd makefile. That way it never runs the test. This is the same solution the IcedTea project does. There is no need to copy over any dylibs. Michael On 12/16/08, Ben Evans wrote: > Hi Greg, > > On Tue, Dec 16, 2008 at 4:59 PM, Greg Lewis wrote: > >> On Tue, Dec 16, 2008 at 11:05:31AM -0500, Michael Franz wrote: >> > I have not built the latest repo, I was working on one from 13/14. >> > There may have been merges done after I did my pull. >> > >> > These errors are in Java code and are unrelated to the patches. >> > Further evidence that the repo has changed since my last build. >> > >> > I will not be able to look at this until tonight. If you can, pull a >> > different revision and try again. >> >> All commits to the repository are sent to this list as far as I can tell. >> I certainly haven't committed any changes since the merge in late November >> that introduced the problem in HotSpot. I have some local hacks >> (different >> from Michael's) to try and get around that, but I'm seeing other errors >> that look like they are due to the version of as on my Mac. >> >> We are pretty due to do some more merging, but I'm hoping our friends at >> Sun (hi Xiaobin!) can maybe come up with an acceptable change they are >> willing to commit to the main repo to fix the HotSpot compile problems. >> >> Ben, it might be worth trying to bootstrap with the version of OpenJDK >> that is available in binary form on Landon Fuller's pages. That is what >> Michael uses. > > > Using the OpenJDK build on Landon's pages enables the patched build to > complete, at least as far as the self-test error mentioned here: > > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-September/000044.html > > As Karen suggests on that page, I've copied the .dylib's over a copy of the > existing JDK build, so I think I have a working build now. > > I'm still struggling to get the invokedynamic patches applied, but that's > another story. > > Thanks, > > Ben > -- Sent from Gmail for mobile | mobile.google.com From mvfranz at gmail.com Tue Dec 16 17:08:37 2008 From: mvfranz at gmail.com (Michael Franz) Date: Tue, 16 Dec 2008 20:08:37 -0500 Subject: _LP64, int32_t and intptr_t In-Reply-To: <20081216165954.GA2893@misty.eyesbeyond.com> References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> Message-ID: Greg, What changes have you made to work around the int32_t, intptr_t problem? On Tue, Dec 16, 2008 at 11:59 AM, Greg Lewis wrote: > If I can get a build going I'd be happy to cut a newer binary and put > it up for download. > It would be nice to have a newer binary for people to try. With the patches that have been made the JRE can be used to run NetBeans (if the startup script is modified to not pass in -XDock) and IntelliJ (by using -Didea.no.jdk.check=true). It will not work Eclipse or SWT applications since we don't have an accepted patch for the -XstartOnFirstThread and there is now way to work around that. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081216/e93935ff/attachment.html From stephen.bannasch at deanbrook.org Tue Dec 16 19:55:42 2008 From: stephen.bannasch at deanbrook.org (Stephen Bannasch) Date: Tue, 16 Dec 2008 22:55:42 -0500 Subject: forest.py for mac In-Reply-To: <20081216201903.GA64879@jon.local> References: <49480B56.8050107@Sun.COM> <20081216201903.GA64879@jon.local> Message-ID: At 12:19 PM -0800 12/16/08, Paul Phillips wrote: >On Tue, Dec 16, 2008 at 12:11:02PM -0800, Xiaobin Lu wrote: >> Anyone could point me out how to get forest.py for Mac? > >hg clone http://hg.akoha.org/hgforest I'm using Patrick M?zard clone (just a couple of fixes to Simons work): hg clone http://bitbucket.org/pmezard/hgforest-crew And after that add an an 'hgext.forest' item with the path to forest.py in the extensions section in your ~/.hgrc file. Here's mine: $ cat ~/.hgrc [ui] username = Stephen Bannasch [extensions] hgext.forest=/Users/stephen/dev/mercurial/hgforest-crew/forest.py From Xiaobin.Lu at Sun.COM Tue Dec 16 23:05:47 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 16 Dec 2008 23:05:47 -0800 Subject: forest.py for mac In-Reply-To: References: <49480B56.8050107@Sun.COM> <20081216201903.GA64879@jon.local> Message-ID: <4948A4CB.7000602@Sun.COM> Thanks so much for all your reply. It works now for me. -Xiaobin Stephen Bannasch wrote: > At 12:19 PM -0800 12/16/08, Paul Phillips wrote: > >> On Tue, Dec 16, 2008 at 12:11:02PM -0800, Xiaobin Lu wrote: >> >>> Anyone could point me out how to get forest.py for Mac? >>> >> hg clone http://hg.akoha.org/hgforest >> > > I'm using Patrick M?zard clone (just a couple of fixes to Simons work): > > hg clone http://bitbucket.org/pmezard/hgforest-crew > > And after that add an an 'hgext.forest' item with the path to > forest.py in the extensions section in your ~/.hgrc file. > > Here's mine: > > $ cat ~/.hgrc > [ui] > username = Stephen Bannasch > [extensions] > hgext.forest=/Users/stephen/dev/mercurial/hgforest-crew/forest.py > > From Xiaobin.Lu at Sun.COM Tue Dec 16 23:20:42 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 16 Dec 2008 23:20:42 -0800 Subject: _LP64, int32_t and intptr_t In-Reply-To: References: Message-ID: <4948A84A.2000203@Sun.COM> Hi Michael, Your patch looks fine to me. For this particular build failure, there is a better solution which someone from our compiler team might want to explore when he has time. A more general problem is the usage of _LP64 which is defined on Solaris x86_64 platform at least. For Mac, I believe we need some similar flag to identify that platform. Anyone know that flag on top of their head? Regards, -Xiaobin Michael Franz wrote: > Hi, > > Looking at assembler_x86.hpp and the usage of _LP64. It seems that > _LP64 is used to decide whether or not to define 32 bit version of > void movptr(Address dst, int32_t imm32); > void movptr(Register dst, int32_t imm32); > to work around casting calls when imm32 would be zero or NULL on 64 > bit platforms. Wouldn't it be better to use the NOT_LP64 and > LP64_ONLY macros with > void MacroAssembler::movptr(Address dst, intptr_t src) > void MacroAssembler::movptr(Register dst, intptr_t src) > instead? This would change the casting to use the intptr_t instead of > int32_t. This would allow the compiler to pick the correct method and > reduce the need for 32 bit only versions. > > The the implementation would be: > void MacroAssembler::movptr(Address dst, intptr_t src) { > #ifdef _LP64 > mov64(rscratch1, src); > movq(dst, rscratch1); > #else > movslq(dst, src); > #endif > } > > void MacroAssembler::movptr(Register dst, intptr_t src) { > LP64_ONLY(mov64(dst, src)) NOT_LP64(movl(dst, src)); > } > would not need to be changed as it already uses the LP64 macros. > > What is interesting that > void MacroAssembler::movptr(Register dst, int32_t src) { > mov64(dst, (intptr_t)src); > } > uses mov64 instead of movl. > > > I have attached the changes I did to get the OS X build to work again. > > Michael From paulp at improving.org Wed Dec 17 06:18:50 2008 From: paulp at improving.org (Paul Phillips) Date: Wed, 17 Dec 2008 06:18:50 -0800 Subject: _LP64, int32_t and intptr_t In-Reply-To: <4948A84A.2000203@Sun.COM> References: <4948A84A.2000203@Sun.COM> Message-ID: <20081217141850.GA4760@jon.local> On Tue, Dec 16, 2008 at 11:20:42PM -0800, Xiaobin Lu wrote: > Your patch looks fine to me. For this particular build failure, there is > a better solution which someone from our compiler team might want to > explore when he has time. The discussion of this issue is becoming tantalizing, now that I've sunk a couple days into getting the mlvm patches working on OS X. Since Iulian's works on linux, I think my remaining issues are most likely due to the mlvm patches needing the same treatment that michael franz gave the main tree. Unfortunately I don't understand the issue well enough to emulate him, and my experiments do not show willy-nilly casts to solve much. Could I persuade one of you guys to elaborate a bit on either the "right" fix or failing that on what mechanistic process might get my mlvm-patched souce tree into a working state? > A more general problem is the usage of _LP64 which is defined on Solaris > x86_64 platform at least. For Mac, I believe we need some similar flag > to identify that platform. Anyone know that flag on top of their head? I believe the flag you want on osx is __LP64__ . See this document: http://developer.apple.com/macosx/64bit.html -- Paul Phillips | A national political campaign is better than the Apatheist | best circus ever heard of, with a mass baptism and Empiricist | a couple of hangings thrown in. ha! spill, pupil | -- H. L. Mencken From Xiaobin.Lu at Sun.COM Wed Dec 17 10:15:37 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 17 Dec 2008 10:15:37 -0800 Subject: [Fwd: Re: _LP64, int32_t and intptr_t] Message-ID: <494941C9.4090709@Sun.COM> -------- Original Message -------- Subject: Re: _LP64, int32_t and intptr_t Date: Wed, 17 Dec 2008 10:14:37 -0800 From: Xiaobin Lu To: Paul Phillips References: <4948A84A.2000203 at Sun.COM> <20081217141850.GA4760 at jon.local> On 12/17/08 06:18, Paul Phillips wrote: > On Tue, Dec 16, 2008 at 11:20:42PM -0800, Xiaobin Lu wrote: > >> Your patch looks fine to me. For this particular build failure, there is >> a better solution which someone from our compiler team might want to >> explore when he has time. >> > > The discussion of this issue is becoming tantalizing, now that I've sunk a couple days into getting the > mlvm patches working on OS X. Since Iulian's works on linux, I think my remaining issues are most likely > due to the mlvm patches needing the same treatment that michael franz gave the main tree. Unfortunately > I don't understand the issue well enough to emulate him, and my experiments do not show willy-nilly casts > to solve much. Could I persuade one of you guys to elaborate a bit on either the "right" fix or failing > that on what mechanistic process might get my mlvm-patched souce tree into a working state? > The right fix is to fix the caller. I could barely understand what our compiler guy told me, so I would rather not to mislead you. I believe the _LP64 misuses are sprinkling into couple other places as well, that is why I think we should perhaps find a way to recognize Mac OS in the VM code and solve it in a more general way. > >> A more general problem is the usage of _LP64 which is defined on Solaris >> x86_64 platform at least. For Mac, I believe we need some similar flag >> to identify that platform. Anyone know that flag on top of their head? >> > > I believe the flag you want on osx is __LP64__ . See this document: > > http://developer.apple.com/macosx/64bit.html > That is what I want. Thanks, Paul. -Xiaobin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081217/d1fe4330/attachment.html From Xiaobin.Lu at Sun.COM Wed Dec 17 16:48:43 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 17 Dec 2008 16:48:43 -0800 Subject: _LP64, int32_t and intptr_t In-Reply-To: References: Message-ID: <49499DEB.6090706@Sun.COM> I am now working on a short term solution (I believe we can live with that for now). A bug will be filed and if that works well on other platforms, I am going to put back the change and let your folks know. Thanks, -Xiaobin On 12/13/08 18:34, Michael Franz wrote: > Hi, > > Looking at assembler_x86.hpp and the usage of _LP64. It seems that > _LP64 is used to decide whether or not to define 32 bit version of > void movptr(Address dst, int32_t imm32); > void movptr(Register dst, int32_t imm32); > to work around casting calls when imm32 would be zero or NULL on 64 > bit platforms. Wouldn't it be better to use the NOT_LP64 and > LP64_ONLY macros with > void MacroAssembler::movptr(Address dst, intptr_t src) > void MacroAssembler::movptr(Register dst, intptr_t src) > instead? This would change the casting to use the intptr_t instead of > int32_t. This would allow the compiler to pick the correct method and > reduce the need for 32 bit only versions. > > The the implementation would be: > void MacroAssembler::movptr(Address dst, intptr_t src) { > #ifdef _LP64 > mov64(rscratch1, src); > movq(dst, rscratch1); > #else > movslq(dst, src); > #endif > } > > void MacroAssembler::movptr(Register dst, intptr_t src) { > LP64_ONLY(mov64(dst, src)) NOT_LP64(movl(dst, src)); > } > would not need to be changed as it already uses the LP64 macros. > > What is interesting that > void MacroAssembler::movptr(Register dst, int32_t src) { > mov64(dst, (intptr_t)src); > } > uses mov64 instead of movl. > > > I have attached the changes I did to get the OS X build to work again. > > Michael From gnu_andrew at member.fsf.org Wed Dec 17 17:17:33 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 18 Dec 2008 01:17:33 +0000 Subject: _LP64, int32_t and intptr_t In-Reply-To: References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> <38a53eb30812161142g91bd92ckd33190f48b8da96b@mail.gmail.com> Message-ID: <17c6771e0812171717j7dfa06d2n695f47232ec0bec8@mail.gmail.com> 2008/12/16 Michael Franz : > Ben, > > What I do for this is, delete the test_gamma from the bsd makefile. > That way it never runs the test. This is the same solution the > IcedTea project does. There is no need to copy over any dylibs. > > Michael > > > > On 12/16/08, Ben Evans wrote: >> Hi Greg, >> >> On Tue, Dec 16, 2008 at 4:59 PM, Greg Lewis wrote: >> >>> On Tue, Dec 16, 2008 at 11:05:31AM -0500, Michael Franz wrote: >>> > I have not built the latest repo, I was working on one from 13/14. >>> > There may have been merges done after I did my pull. >>> > >>> > These errors are in Java code and are unrelated to the patches. >>> > Further evidence that the repo has changed since my last build. >>> > >>> > I will not be able to look at this until tonight. If you can, pull a >>> > different revision and try again. >>> >>> All commits to the repository are sent to this list as far as I can tell. >>> I certainly haven't committed any changes since the merge in late November >>> that introduced the problem in HotSpot. I have some local hacks >>> (different >>> from Michael's) to try and get around that, but I'm seeing other errors >>> that look like they are due to the version of as on my Mac. >>> >>> We are pretty due to do some more merging, but I'm hoping our friends at >>> Sun (hi Xiaobin!) can maybe come up with an acceptable change they are >>> willing to commit to the main repo to fix the HotSpot compile problems. >>> >>> Ben, it might be worth trying to bootstrap with the version of OpenJDK >>> that is available in binary form on Landon Fuller's pages. That is what >>> Michael uses. >> >> >> Using the OpenJDK build on Landon's pages enables the patched build to >> complete, at least as far as the self-test error mentioned here: >> >> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2008-September/000044.html >> >> As Karen suggests on that page, I've copied the .dylib's over a copy of the >> existing JDK build, so I think I have a working build now. >> >> I'm still struggling to get the invokedynamic patches applied, but that's >> another story. >> >> Thanks, >> >> Ben >> > > -- > Sent from Gmail for mobile | mobile.google.com > > IcedTea only does this for the ecj build AFAICS. test_gamma is still run for the icedtea-against-icedtea stage. -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Xiaobin.Lu at Sun.COM Wed Dec 17 18:28:35 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 17 Dec 2008 18:28:35 -0800 Subject: Where are we on 64 bit build Message-ID: <4949B553.6080206@Sun.COM> I noticed that the 64 bit hotspot build fails even after I fixed one problem after another, so I am wondering where we are standing on 64 bit build. -Xiaobin (I am new to this porting work, so please bear with me.) From mvfranz at gmail.com Wed Dec 17 18:38:21 2008 From: mvfranz at gmail.com (Michael Franz) Date: Wed, 17 Dec 2008 21:38:21 -0500 Subject: _LP64, int32_t and intptr_t In-Reply-To: <17c6771e0812171717j7dfa06d2n695f47232ec0bec8@mail.gmail.com> References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> <38a53eb30812161142g91bd92ckd33190f48b8da96b@mail.gmail.com> <17c6771e0812171717j7dfa06d2n695f47232ec0bec8@mail.gmail.com> Message-ID: On Wed, Dec 17, 2008 at 8:17 PM, Andrew John Hughes < gnu_andrew at member.fsf.org> wrote: > 2008/12/16 Michael Franz : > > Ben, > > > > What I do for this is, delete the test_gamma from the bsd makefile. > > That way it never runs the test. This is the same solution the > > IcedTea project does. There is no need to copy over any dylibs. > > > > Michael > > > IcedTea only does this for the ecj build AFAICS. test_gamma is still > run for the icedtea-against-icedtea stage. > -- > Andrew :-) > I wonder why I have never been able to get the test_gamma test to work. Ant also acts funny on the OS X build. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081217/92deb7ce/attachment.html From mvfranz at gmail.com Wed Dec 17 18:39:29 2008 From: mvfranz at gmail.com (Michael Franz) Date: Wed, 17 Dec 2008 21:39:29 -0500 Subject: Where are we on 64 bit build In-Reply-To: <4949B553.6080206@Sun.COM> References: <4949B553.6080206@Sun.COM> Message-ID: Xiaobin, What OS are you using for the 64 bit build? Michael On Wed, Dec 17, 2008 at 9:28 PM, Xiaobin Lu wrote: > I noticed that the 64 bit hotspot build fails even after I fixed one > problem after another, so I am wondering where we are standing on 64 bit > build. > > -Xiaobin > (I am new to this porting work, so please bear with me.) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081217/a4cb5b9b/attachment.html From Xiaobin.Lu at Sun.COM Wed Dec 17 18:46:57 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 17 Dec 2008 18:46:57 -0800 Subject: Where are we on 64 bit build In-Reply-To: References: <4949B553.6080206@Sun.COM> Message-ID: <4949B9A1.5020906@Sun.COM> On 12/17/08 18:39, Michael Franz wrote: > Xiaobin, > > What OS are you using for the 64 bit build? Michael, I am using Mac OS 10.5.5. After I made a few changes, the build is ok now. Also I noticed that the flag to make 64 bit VM is no longer to be BSD_OVERRIDE_ARCH=amd64 as pointed by Landon's page. Instead LP64=1 is working just like we do for other 64 bit platforms which is good. I am going to do more testings before I propose the change. I am thinking to check in these changes to our open jdk 7 tree. After that, your folks can make the merge. Thanks, -Xiaobin > > Michael > > On Wed, Dec 17, 2008 at 9:28 PM, Xiaobin Lu > wrote: > > I noticed that the 64 bit hotspot build fails even after I fixed one > problem after another, so I am wondering where we are standing on > 64 bit > build. > > -Xiaobin > (I am new to this porting work, so please bear with me.) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081217/feede66a/attachment.html From Xiaobin.Lu at Sun.COM Wed Dec 17 21:14:16 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 17 Dec 2008 21:14:16 -0800 Subject: Patch to build 64 bit VM Message-ID: <4949DC28.6020703@Sun.COM> I am attaching the patch for building 64 bit VM. They are BSD specific files. Would someone review it and help me check it in? Thanks, -Xiaobin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch_12_17_amd64 Url: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081217/0fe1aaaf/attachment.ksh From Xiaobin.Lu at Sun.COM Wed Dec 17 21:23:31 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 17 Dec 2008 21:23:31 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <4949DC28.6020703@Sun.COM> References: <4949DC28.6020703@Sun.COM> Message-ID: <4949DE53.8080703@Sun.COM> I cut the wrong line from the other patch when I generated the attached patch. The first line should be: diff -r de4c58dbee8f src/cpu/x86/vm/stubGenerator_x86_64.cpp Sorry for confusion. -Xiaobin Xiaobin Lu wrote: > I am attaching the patch for building 64 bit VM. They are BSD specific > files. Would someone review it and help me check it in? > > Thanks, > -Xiaobin > ------------------------------------------------------------------------ > > From benjamin.john.evans at googlemail.com Thu Dec 18 06:44:40 2008 From: benjamin.john.evans at googlemail.com (Ben Evans) Date: Thu, 18 Dec 2008 14:44:40 +0000 Subject: _LP64, int32_t and intptr_t In-Reply-To: References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> <38a53eb30812161142g91bd92ckd33190f48b8da96b@mail.gmail.com> Message-ID: <38a53eb30812180644w69b6b76bw1080961871a38093@mail.gmail.com> On Tue, Dec 16, 2008 at 10:47 PM, Michael Franz wrote: > > What I do for this is, delete the test_gamma from the bsd makefile. > That way it never runs the test. This is the same solution the > IcedTea project does. There is no need to copy over any dylibs. > After deleting the test_gamma everything seems to build fine, and the resulting SDK will happily build OpenJDK afgain. Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081218/4ecaa1cb/attachment.html From Kelly.Ohair at Sun.COM Thu Dec 18 10:18:22 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Thu, 18 Dec 2008 10:18:22 -0800 Subject: _LP64, int32_t and intptr_t In-Reply-To: <38a53eb30812180644w69b6b76bw1080961871a38093@mail.gmail.com> References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> <38a53eb30812161142g91bd92ckd33190f48b8da96b@mail.gmail.com> <38a53eb30812180644w69b6b76bw1080961871a38093@mail.gmail.com> Message-ID: <494A93EE.5050507@sun.com> FYI... just for informational purposes... test_gamma is a bit of an unusual beast, it wants to use the freshly built libjvm.so with a jdk to see if it works, but in building a jdk for the very first time, there may not be an acceptable jdk to test drive this VM just yet because the VM is one of the first things built. I've always thought that this test_gamma logic should be restricted to builds of hotspot where a suitable previously built jdk is available. Sometimes that's the boot jdk (ALT_BOOTDIR or JAVA_HOME) or maybe the optional import jdk (JDK_IMPORT_PATH) used when doing partial jdk builds. But with many of these initial porting efforts, neither may make sense or will work. Not sure how to detect this situation automatically. -kto Ben Evans wrote: > On Tue, Dec 16, 2008 at 10:47 PM, Michael Franz > wrote: > > > What I do for this is, delete the test_gamma from the bsd makefile. > That way it never runs the test. This is the same solution the > IcedTea project does. There is no need to copy over any dylibs. > > > After deleting the test_gamma everything seems to build fine, and the > resulting SDK will happily build OpenJDK afgain. > > Thanks, > > Ben > > > ------------------------------------------------------------------------ > > From Xiaobin.Lu at Sun.COM Thu Dec 18 12:20:36 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Thu, 18 Dec 2008 12:20:36 -0800 Subject: _LP64, int32_t and intptr_t In-Reply-To: <49499DEB.6090706@Sun.COM> References: <49499DEB.6090706@Sun.COM> Message-ID: <494AB094.3040503@Sun.COM> FYI, bug "6787106: Created P3 hotspot/other Hotspot 32 bit build fails on platforms having different definitions for intptr_t & int32_t" has been filed and the fix is on the way. -Xiaobin On 12/17/08 16:48, Xiaobin Lu wrote: > I am now working on a short term solution (I believe we can live with > that for now). A bug will be filed and if that works well on other > platforms, I am going to put back the change and let your folks know. > > Thanks, > -Xiaobin > > On 12/13/08 18:34, Michael Franz wrote: > >> Hi, >> >> Looking at assembler_x86.hpp and the usage of _LP64. It seems that >> _LP64 is used to decide whether or not to define 32 bit version of >> void movptr(Address dst, int32_t imm32); >> void movptr(Register dst, int32_t imm32); >> to work around casting calls when imm32 would be zero or NULL on 64 >> bit platforms. Wouldn't it be better to use the NOT_LP64 and >> LP64_ONLY macros with >> void MacroAssembler::movptr(Address dst, intptr_t src) >> void MacroAssembler::movptr(Register dst, intptr_t src) >> instead? This would change the casting to use the intptr_t instead of >> int32_t. This would allow the compiler to pick the correct method and >> reduce the need for 32 bit only versions. >> >> The the implementation would be: >> void MacroAssembler::movptr(Address dst, intptr_t src) { >> #ifdef _LP64 >> mov64(rscratch1, src); >> movq(dst, rscratch1); >> #else >> movslq(dst, src); >> #endif >> } >> >> void MacroAssembler::movptr(Register dst, intptr_t src) { >> LP64_ONLY(mov64(dst, src)) NOT_LP64(movl(dst, src)); >> } >> would not need to be changed as it already uses the LP64 macros. >> >> What is interesting that >> void MacroAssembler::movptr(Register dst, int32_t src) { >> mov64(dst, (intptr_t)src); >> } >> uses mov64 instead of movl. >> >> >> I have attached the changes I did to get the OS X build to work again. >> >> Michael >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081218/2a50e892/attachment.html From Xiaobin.Lu at Sun.COM Fri Dec 19 11:42:34 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 19 Dec 2008 11:42:34 -0800 Subject: review request for 6787106 Message-ID: <494BF92A.405@Sun.COM> http://webrev.invokedynamic.info/xiaobin.lu/6787106/webrev/ CR 6787106: Hotspot 32 bit build fails on platforms having different definitions for intptr_t & int32_t Details: This bug was filed to fix the build failure on Mac OS X and I believe it is a good practice to put back the fix in Openjdk so that the BSD folks or whoever maintain the BSD port could merge the fix into their tree. Basically on Mac OS X, intptr_t & int32_t are not the same type on 32 bit platform and intptr_t and int64_t are not the same either. The former is typedefed as "long" and the latter is typedefed as "int" (or long long for int64_t). Those are usually same types on platforms such as Windows, Solaris and different flavors of Linux. Somewhere in our code, we assume they are the same type and that is where the problem arouse. In assembler_x86.hpp, we have the following definitions in MacroAssembler class: void movptr(Address dst, intptr_t src); void movptr(Address dst, Reigster src); (Register is defined as RegisterImpl*) And when we want to clear some destination address, we simply call "movptr(dest, (int32_t)NULL_WORD);". The cast is necessary to resolve the call to the one which accepts intptr_t as the second parameter. Well, this works on platforms which treat intptr_t & int32_t the same, but will break on other platforms which do not, hence, the build failed. My fix is to redefine NULL_WORD on 32 bit a little bit different, instead of define NULL_WORD as "0", I defined it as "(intptr_t)0". With that, in the places where we want to call "movptr(dest, (int32_t)NULL_WORD);", we can simply call "movptr(dest, NULL_WORD);", therefore, no ambiguity. Tom has a better solution which might address this in a more elegant way, but I don't believe we have enough time to address that in short term and I believe the solution I am suggesting here is ok at least to give a good build on Mac. Reviewed by: Verified by: JPRT Build passed on 32 bit & 64 bit Mac OS 10.5.5. Thanks, -Xiaobin From Xiaobin.Lu at Sun.COM Fri Dec 19 15:57:36 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 19 Dec 2008 15:57:36 -0800 Subject: A process question Message-ID: <494C34F0.5030500@Sun.COM> Hi folks, While I am working a fix to make the build pass on Mac OS, I notice that for some files, I could go head and just check it into the open jdk 7 tree and let someone take care of the merge, but I am encountering one file that I need to change (os_bsd_x86.cpp) in order to make the 64 bit pass. Would someone help me clarify how the put back process we are using here? How can I get the check in permission etc? Thanks so much in advance! -Xiaobin From mvfranz at gmail.com Fri Dec 19 16:26:51 2008 From: mvfranz at gmail.com (Michael Franz) Date: Fri, 19 Dec 2008 19:26:51 -0500 Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display Message-ID: Hi, I am running NetBeans on OS X using OpenJDK 7. This uses the X11 implementation as there is no native Cocoa/Carbon Swing implementation. There are a few quirks that I would like to mention, maybe someone can indicate what part of the code these issue are in. 1. Menus - the cursor is sometimes 1 line item below what is highlighted 2. Dual display - opening new dialogs are centered between the displays (not the current display netbeans is in). 3. The log file has many of these exceptions: java.net.SocketException: Invalid argument at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:364) at java.net.ServerSocket.implAccept(ServerSocket.java:513) at java.net.ServerSocket.accept(ServerSocket.java:481) at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010) Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081219/f5147ea6/attachment.html From Xiaobin.Lu at Sun.COM Fri Dec 19 17:22:22 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Fri, 19 Dec 2008 17:22:22 -0800 Subject: NetBeans Under OpenJDK 7 On OS X - Dual Display In-Reply-To: References: Message-ID: <494C48CE.5010001@Sun.COM> We noticed some similar exceptions when we ran some testings here. I believe the relevant code is in the java networking code. I am ccing Brad here and he might have more information on how to get around this. -Xiaobin On 12/19/08 16:26, Michael Franz wrote: > Hi, > > I am running NetBeans on OS X using OpenJDK 7. This uses the X11 > implementation as there is no native Cocoa/Carbon Swing > implementation. There are a few quirks that I would like to mention, > maybe someone can indicate what part of the code these issue are in. > > 1. Menus - the cursor is sometimes 1 line item below what is highlighted > 2. Dual display - opening new dialogs are centered between the > displays (not the current display netbeans is in). > 3. The log file has many of these exceptions: > java.net.SocketException: Invalid argument > at java.net.PlainSocketImpl.socketAccept(Native Method) > at > java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:364) > at java.net.ServerSocket.implAccept(ServerSocket.java:513) > at java.net.ServerSocket.accept(ServerSocket.java:481) > at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1010) > > > Michael > ------------------------------------------------------------------------ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081219/5f03e431/attachment.html From swingler at apple.com Sat Dec 20 15:30:13 2008 From: swingler at apple.com (Mike Swingler) Date: Sat, 20 Dec 2008 15:30:13 -0800 Subject: XStartOnFirstThread - Possible Patch In-Reply-To: References: Message-ID: <2C2E942F-15A0-4097-A370-421879238EA7@apple.com> On Dec 2, 2008, at 7:48 PM, Michael Franz wrote: > Hi, > > Here is one way of adding -XstartOnFirstThread for OS X. I copied > the logic from other parts of the launcher and not too sure if all > of the code in the new ContinueInSameThread function is needed. > Please review and comment. This implementation looks good. It's much simpler than our own (which has other gunk in place for the benefit of our Cocoa/AppKit-based AWT). Cheers, Mike Swingler Java Runtime Engineer Apple Inc. From mvfranz at gmail.com Sat Dec 20 17:28:27 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sat, 20 Dec 2008 20:28:27 -0500 Subject: Native Socket Error On OS X (BSDs) Message-ID: Hi, I have been getting this error when running different applications under the OpenJDK for OS X. Dec 20, 2008 8:20:33 PM sun.rmi.transport.tcp.TCPTransport$AcceptLoop executeAcceptLoop WARNING: RMI TCP Accept-0: accept loop for ServerSocket[addr= 0.0.0.0/0.0.0.0,port=0,localport=56982] throws java.net.SocketException: Invalid argument at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:364) at java.net.ServerSocket.implAccept(ServerSocket.java:513) at java.net.ServerSocket.accept(ServerSocket.java:481) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359) at java.lang.Thread.run(Thread.java:713) I am not sure what is initiating this error. I am running tests with TestNG that is doing JDBC calls, using ActiveMQ and QuickFIX/J. All using tcp sockets. Doing some research it seems that there might be some general problem with BSD sockets that causes this problem: http://lists.apple.com/archives/macnetworkprog/2008/Aug/msg00063.html Is anyone familiar with this issue? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081220/dbb622c8/attachment.html From John.Rose at Sun.COM Fri Dec 19 13:33:56 2008 From: John.Rose at Sun.COM (John Rose) Date: Fri, 19 Dec 2008 13:33:56 -0800 Subject: review request for 6787106 In-Reply-To: <494BF92A.405@Sun.COM> References: <494BF92A.405@Sun.COM> Message-ID: <84BEECB7-A6D4-42AF-9B4C-879EA15D2356@sun.com> +1 for BSD support, +1 for fewer casts, +1 for 32/64 source convergence! Two minor comments: Don't replace a name by a naked constant; use a cast in templateTable_x86_32: - __ movl(Address(rdx, 0), NULL_WORD); + __ movl(Address(rdx, 0), 0); ++ __ movl(Address(rdx, 0), (int32_t)NULL_WORD); It would be better to put parens around the macro definition: - #define NULL_WORD 0 + #define NULL_WORD (intptr_t)0 ++ #define NULL_WORD ((intptr_t)0) Reviewed. -- John On Dec 19, 2008, at 11:42 AM, Xiaobin Lu wrote: > http://webrev.invokedynamic.info/xiaobin.lu/6787106/webrev/ > > CR 6787106: Hotspot 32 bit build fails on platforms having > different definitions for intptr_t & int32_t -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081219/75f3759a/attachment.html From mvfranz at gmail.com Sun Dec 21 18:16:41 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 21 Dec 2008 21:16:41 -0500 Subject: Native Socket Error On OS X (BSDs) In-Reply-To: References: Message-ID: Hi, I have been investigating this more and been trying to figure out where NET_Timeout is defined on OS X. It is being called in PlanSocketImpl.c. There are two definitions that I have found, one for linux and one for bsd. A third uses JVM_Timeout. The bsd version is specific to FreeBSD. Are there known issues with JVM_Timeout? Why does Linux and FreeBSD need definitions that are different from the one in Hotspot? jdk/src/solaris/native/java/net/bsd_close.c jdk/src/solaris/native/java/net/linux_close.c hotspot/src/os/bsd/vm/hpi_bsd.hpp I changed the inline int hpi::timeout(int fd, long timeout) method to not use the Apple specific code and I think the problem is fixed (at least for me). #ifdef __APPLE__ // XXXDARWIN: poll() appears non-interruptable on Leopard: Thread.interrupt() failed to // cause interrupt. Does poll work at all on Tiger? Needs investigation. fd_set fdset; struct timeval seltv; FD_ZERO(&fdset); FD_SET(fd, &fdset); seltv.tv_sec = timeout / 1000; seltv.tv_usec = (timeout % 1000) * 1000; INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL, &seltv), res, os::Bsd::clear_interrupted); #else struct pollfd pfd; pfd.fd = fd; pfd.events = POLLIN | POLLERR; INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res, os::Bsd::clear_interrupted); #endif Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081221/8920ad09/attachment.html From glewis at eyesbeyond.com Mon Dec 22 05:54:56 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Mon, 22 Dec 2008 05:54:56 -0800 Subject: _LP64, int32_t and intptr_t In-Reply-To: References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> Message-ID: <20081222135456.GA96610@misty.eyesbeyond.com> On Tue, Dec 16, 2008 at 08:08:37PM -0500, Michael Franz wrote: > What changes have you made to work around the int32_t, intptr_t problem? Attached is as far as I got before I ran into problems with the assembler choking on stuff that wasn't changed. These aren't the right changes, but they were the least intrusive to other code. BTW, can you tell me what version of as(1) you're using? Just the output of 'as -v' would be great. > On Tue, Dec 16, 2008 at 11:59 AM, Greg Lewis wrote: > > > If I can get a build going I'd be happy to cut a newer binary and put > > it up for download. > > > > It would be nice to have a newer binary for people to try. With the patches > that have been made the JRE can be used to run NetBeans (if the startup > script is modified to not pass in -XDock) and IntelliJ (by using > -Didea.no.jdk.check=true). It will not work Eclipse or SWT applications > since we don't have an accepted patch for the -XstartOnFirstThread and there > is now way to work around that. > > Michael -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org -------------- next part -------------- A non-text attachment was scrubbed... Name: mac.diff Type: text/x-diff Size: 2053 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081222/3f0381c1/attachment.bin From glewis at eyesbeyond.com Mon Dec 22 06:04:54 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Mon, 22 Dec 2008 06:04:54 -0800 Subject: A process question In-Reply-To: <494C34F0.5030500@Sun.COM> References: <494C34F0.5030500@Sun.COM> Message-ID: <20081222140454.GB96610@misty.eyesbeyond.com> G'day Xiaobin, On Fri, Dec 19, 2008 at 03:57:36PM -0800, Xiaobin Lu wrote: > While I am working a fix to make the build pass on Mac OS, I notice that > for some files, I could go head and just check it into the open jdk 7 > tree and let someone take care of the merge, but I am encountering one > file that I need to change (os_bsd_x86.cpp) in order to make the 64 bit > pass. > > Would someone help me clarify how the put back process we are using > here? How can I get the check in permission etc? > > Thanks so much in advance! I'd be happy to check in the changes for you. I'd also be happy to help arrange for access for you if that would be easier. I believe Dalibor Topic can help with that. -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From glewis at eyesbeyond.com Mon Dec 22 06:09:53 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Mon, 22 Dec 2008 06:09:53 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <4949DC28.6020703@Sun.COM> References: <4949DC28.6020703@Sun.COM> Message-ID: <20081222140953.GC96610@misty.eyesbeyond.com> G'day Xiaobin, On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: > I am attaching the patch for building 64 bit VM. They are BSD specific > files. Would someone review it and help me check it in? Sure. Can you comment a little on the changes to src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is bigger than the changes if that makes sense (i.e. there are some whitespace changes due to control flow changes which are hiding those). > diff -r de4c58dbee8f src/cpu/x86/vm/stubGenerator_x86_32.cpp > --- a/src/cpu/x86/vm/stubGenerator_x86_64.cpp Wed Nov 26 05:05:13 2008 -0800 > +++ b/src/cpu/x86/vm/stubGenerator_x86_64.cpp Wed Dec 17 21:06:49 2008 -0800 > @@ -954,9 +954,9 @@ class StubGenerator: public StubCodeGene > __ jcc(Assembler::zero, exit); // if obj is NULL it is OK > // Check if the oop is in the right area of memory > __ movptr(c_rarg2, rax); > - __ movptr(c_rarg3, (int64_t) Universe::verify_oop_mask()); > + __ movptr(c_rarg3, (intptr_t) Universe::verify_oop_mask()); > __ andptr(c_rarg2, c_rarg3); > - __ movptr(c_rarg3, (int64_t) Universe::verify_oop_bits()); > + __ movptr(c_rarg3, (intptr_t) Universe::verify_oop_bits()); > __ cmpptr(c_rarg2, c_rarg3); > __ jcc(Assembler::notZero, error); > > @@ -969,9 +969,9 @@ class StubGenerator: public StubCodeGene > __ jcc(Assembler::zero, error); // if klass is NULL it is broken > // Check if the klass is in the right area of memory > __ mov(c_rarg2, rax); > - __ movptr(c_rarg3, (int64_t) Universe::verify_klass_mask()); > + __ movptr(c_rarg3, (intptr_t) Universe::verify_klass_mask()); > __ andptr(c_rarg2, c_rarg3); > - __ movptr(c_rarg3, (int64_t) Universe::verify_klass_bits()); > + __ movptr(c_rarg3, (intptr_t) Universe::verify_klass_bits()); > __ cmpptr(c_rarg2, c_rarg3); > __ jcc(Assembler::notZero, error); > > @@ -980,9 +980,9 @@ class StubGenerator: public StubCodeGene > __ testptr(rax, rax); > __ jcc(Assembler::zero, error); // if klass' klass is NULL it is broken > // Check if the klass' klass is in the right area of memory > - __ movptr(c_rarg3, (int64_t) Universe::verify_klass_mask()); > + __ movptr(c_rarg3, (intptr_t) Universe::verify_klass_mask()); > __ andptr(rax, c_rarg3); > - __ movptr(c_rarg3, (int64_t) Universe::verify_klass_bits()); > + __ movptr(c_rarg3, (intptr_t) Universe::verify_klass_bits()); > __ cmpptr(rax, c_rarg3); > __ jcc(Assembler::notZero, error); > > diff -r de4c58dbee8f src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp > --- a/src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp Wed Nov 26 05:05:13 2008 -0800 > +++ b/src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp Wed Dec 17 21:06:49 2008 -0800 > @@ -32,9 +32,9 @@ > > #if defined(AMD64) > # if defined(__APPLE__) > -# define bswap16(x) OSSwapInt16(x) > -# define bswap32(x) OSSwapInt32(x) > -# define bswap64(x) OSSwapInt64(x) > +# define bswap_16(x) OSSwapInt16(x) > +# define bswap_32(x) OSSwapInt32(x) > +# define bswap_64(x) OSSwapInt64(x) > # elif defined(__OpenBSD__) > # define bswap_16(x) swap16(x) > # define bswap_32(x) swap32(x) > diff -r de4c58dbee8f src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > --- a/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Wed Nov 26 05:05:13 2008 -0800 > +++ b/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Wed Dec 17 21:06:49 2008 -0800 > @@ -456,197 +456,191 @@ JVM_handle_bsd_signal(int sig, > if (nm != NULL && nm->has_unsafe_access()) { > stub = StubRoutines::handler_for_unsafe_access(); > } > + } else { > +#if defined(AMD64) && !defined(__APPLE__) > + if (sig == SIGFPE && > + (info->si_code == FPE_INTDIV || info->si_code == FPE_FLTDIV)) { > + stub = > + SharedRuntime:: > + continuation_for_implicit_exception(thread, > + pc, > + SharedRuntime:: > + IMPLICIT_DIVIDE_BY_ZERO); > +#else > + if (sig == SIGFPE /* && info->si_code == FPE_INTDIV */) { > + // HACK: si_code does not work on bsd 2.2.12-20!!! > + int op = pc[0]; > +# ifdef AMD64 > + // Skip REX > + if ((pc[0] & 0xf0) == 0x40) { > + op = pc[1]; > +# endif > + if (op == 0xDB) { > + // FIST > + // TODO: The encoding of D2I in i486.ad can cause an exception > + // prior to the fist instruction if there was an invalid operation > + // pending. We want to dismiss that exception. From the win_32 > + // side it also seems that if it really was the fist causing > + // the exception that we do the d2i by hand with different > + // rounding. Seems kind of weird. > + // NOTE: that we take the exception at the NEXT floating point instruction. > + assert(pc[0] == 0xDB, "not a FIST opcode"); > + assert(pc[1] == 0x14, "not a FIST opcode"); > + assert(pc[2] == 0x24, "not a FIST opcode"); > + return true; > + } else if (op == 0xF7) { > + // IDIV > + stub = SharedRuntime::continuation_for_implicit_exception(thread, pc, SharedRuntime::IMPLICIT_DIVIDE_BY_ZERO); > + } else { > + // TODO: handle more cases if we are using other x86 instructions > + // that can generate SIGFPE signal on bsd. > + tty->print_cr("unknown opcode 0x%X with SIGFPE.", op); > + fatal("please update this code."); > + } > +#endif // AMD64 > + } else if ((sig == SIGSEGV || sig == SIGBUS) && > + !MacroAssembler::needs_explicit_null_check((intptr_t)info->si_addr)) { > + // Determination of interpreter/vtable stub/compiled code null exception > + stub = SharedRuntime::continuation_for_implicit_exception(thread, pc, SharedRuntime::IMPLICIT_NULL); > + } > + } else if (thread->thread_state() == _thread_in_vm && > + sig == SIGBUS && /* info->si_code == BUS_OBJERR && */ > + thread->doing_unsafe_access()) { > + stub = StubRoutines::handler_for_unsafe_access(); > + } > + > + // jni_fast_GetField can trap at certain pc's if a GC kicks in > + // and the heap gets shrunk before the field access. > + if ((sig == SIGSEGV) || (sig == SIGBUS)) { > + address addr = JNI_FastGetField::find_slowcase_pc(pc); > + if (addr != (address)-1) { > + stub = addr; > + } > + } > + > + // Check to see if we caught the safepoint code in the > + // process of write protecting the memory serialization page. > + // It write enables the page immediately after protecting it > + // so we can just return to retry the write. > + if ((sig == SIGSEGV || sig == SIGBUS) && > + os::is_memory_serialize_page(thread, (address) info->si_addr)) { > + // Block current thread until the memory serialize page permission restored. > + os::block_on_serialize_page_trap(); > + return true; > + } > } > - else > +#ifndef AMD64 > + // Execution protection violation > + // > + // This should be kept as the last step in the triage. We don't > + // have a dedicated trap number for a no-execute fault, so be > + // conservative and allow other handlers the first shot. > + // > + // Note: We don't test that info->si_code == SEGV_ACCERR here. > + // this si_code is so generic that it is almost meaningless; and > + // the si_code for this condition may change in the future. > + // Furthermore, a false-positive should be harmless. > + if (UnguardOnExecutionViolation > 0 && > + (sig == SIGSEGV || sig == SIGBUS) && > + uc->context_trapno == trap_page_fault) { > + int page_size = os::vm_page_size(); > + address addr = (address) info->si_addr; > + address pc = os::Bsd::ucontext_get_pc(uc); > + // Make sure the pc and the faulting address are sane. > + // > + // If an instruction spans a page boundary, and the page containing > + // the beginning of the instruction is executable but the following > + // page is not, the pc and the faulting address might be slightly > + // different - we still want to unguard the 2nd page in this case. > + // > + // 15 bytes seems to be a (very) safe value for max instruction size. > + bool pc_is_near_addr = > + (pointer_delta((void*) addr, (void*) pc, sizeof(char)) < 15); > + bool instr_spans_page_boundary = > + (align_size_down((intptr_t) pc ^ (intptr_t) addr, > + (intptr_t) page_size) > 0); > > -#if defined(AMD64) && !defined(__APPLE__) > - if (sig == SIGFPE && > - (info->si_code == FPE_INTDIV || info->si_code == FPE_FLTDIV)) { > - stub = > - SharedRuntime:: > - continuation_for_implicit_exception(thread, > - pc, > - SharedRuntime:: > - IMPLICIT_DIVIDE_BY_ZERO); > + if (pc == addr || (pc_is_near_addr && instr_spans_page_boundary)) { > + static volatile address last_addr = > + (address) os::non_memory_address_word(); > > -#else > - if (sig == SIGFPE /* && info->si_code == FPE_INTDIV */) { > - // HACK: si_code does not work on bsd 2.2.12-20!!! > - int op = pc[0]; > + // In conservative mode, don't unguard unless the address is in the VM > + if (addr != last_addr && > + (UnguardOnExecutionViolation > 1 || os::address_is_in_vm(addr))) { > + > + // Unguard and retry > + address page_start = > + (address) align_size_down((intptr_t) addr, (intptr_t) page_size); > + bool res = os::unguard_memory((char*) page_start, page_size); > + > + if (PrintMiscellaneous && Verbose) { > + char buf[256]; > + jio_snprintf(buf, sizeof(buf), "Execution protection violation " > + "at " INTPTR_FORMAT > + ", unguarding " INTPTR_FORMAT ": %s, errno=%d", addr, > + page_start, (res ? "success" : "failed"), errno); > + tty->print_raw_cr(buf); > + } > + stub = pc; > + > + // Set last_addr so if we fault again at the same address, we don't end > + // up in an endless loop. > + // > + // There are two potential complications here. Two threads trapping at > + // the same address at the same time could cause one of the threads to > + // think it already unguarded, and abort the VM. Likely very rare. > + // > + // The other race involves two threads alternately trapping at > + // different addresses and failing to unguard the page, resulting in > + // an endless loop. This condition is probably even more unlikely than > + // the first. > + // > + // Although both cases could be avoided by using locks or thread local > + // last_addr, these solutions are unnecessary complication: this > + // handler is a best-effort safety net, not a complete solution. It is > + // disabled by default and should only be used as a workaround in case > + // we missed any no-execute-unsafe VM code. > + > + last_addr = addr; > + } > + } > + } > +#endif // !AMD64 > + if (stub != NULL) { > + // save all thread context in case we need to restore it > + if (thread != NULL) thread->set_saved_exception_pc(pc); > > -# ifdef AMD64 > - // Skip REX > - if ((pc[0] & 0xf0) == 0x40) { > - op = pc[1]; > -# endif > - > - if (op == 0xDB) { > - // FIST > - // TODO: The encoding of D2I in i486.ad can cause an exception > - // prior to the fist instruction if there was an invalid operation > - // pending. We want to dismiss that exception. From the win_32 > - // side it also seems that if it really was the fist causing > - // the exception that we do the d2i by hand with different > - // rounding. Seems kind of weird. > - // NOTE: that we take the exception at the NEXT floating point instruction. > - assert(pc[0] == 0xDB, "not a FIST opcode"); > - assert(pc[1] == 0x14, "not a FIST opcode"); > - assert(pc[2] == 0x24, "not a FIST opcode"); > - return true; > - } else if (op == 0xF7) { > - // IDIV > - stub = SharedRuntime::continuation_for_implicit_exception(thread, pc, SharedRuntime::IMPLICIT_DIVIDE_BY_ZERO); > - } else { > - // TODO: handle more cases if we are using other x86 instructions > - // that can generate SIGFPE signal on bsd. > - tty->print_cr("unknown opcode 0x%X with SIGFPE.", op); > - fatal("please update this code."); > - } > -#endif // AMD64 > - } else if ((sig == SIGSEGV || sig == SIGBUS) && > - !MacroAssembler::needs_explicit_null_check((intptr_t)info->si_addr)) { > - // Determination of interpreter/vtable stub/compiled code null exception > - stub = SharedRuntime::continuation_for_implicit_exception(thread, pc, SharedRuntime::IMPLICIT_NULL); > + uc->context_pc = (intptr_t)stub; > + return true; > } > - } else if (thread->thread_state() == _thread_in_vm && > - sig == SIGBUS && /* info->si_code == BUS_OBJERR && */ > - thread->doing_unsafe_access()) { > - stub = StubRoutines::handler_for_unsafe_access(); > - } > > - // jni_fast_GetField can trap at certain pc's if a GC kicks in > - // and the heap gets shrunk before the field access. > - if ((sig == SIGSEGV) || (sig == SIGBUS)) { > - address addr = JNI_FastGetField::find_slowcase_pc(pc); > - if (addr != (address)-1) { > - stub = addr; > + // signal-chaining > + if (os::Bsd::chained_handler(sig, info, ucVoid)) { > + return true; > } > - } > > - // Check to see if we caught the safepoint code in the > - // process of write protecting the memory serialization page. > - // It write enables the page immediately after protecting it > - // so we can just return to retry the write. > - if ((sig == SIGSEGV || sig == SIGBUS) && > - os::is_memory_serialize_page(thread, (address) info->si_addr)) { > - // Block current thread until the memory serialize page permission restored. > - os::block_on_serialize_page_trap(); > - return true; > + if (!abort_if_unrecognized) { > + // caller wants another chance, so give it to him > + return false; > + } > + > + if (pc == NULL && uc != NULL) { > + pc = os::Bsd::ucontext_get_pc(uc); > + } > + > + // unmask current signal > + sigset_t newset; > + sigemptyset(&newset); > + sigaddset(&newset, sig); > + sigprocmask(SIG_UNBLOCK, &newset, NULL); > + > + VMError err(t, sig, pc, info, ucVoid); > + err.report_and_die(); > + > + ShouldNotReachHere(); > } > } > - > -#ifndef AMD64 > - // Execution protection violation > - // > - // This should be kept as the last step in the triage. We don't > - // have a dedicated trap number for a no-execute fault, so be > - // conservative and allow other handlers the first shot. > - // > - // Note: We don't test that info->si_code == SEGV_ACCERR here. > - // this si_code is so generic that it is almost meaningless; and > - // the si_code for this condition may change in the future. > - // Furthermore, a false-positive should be harmless. > - if (UnguardOnExecutionViolation > 0 && > - (sig == SIGSEGV || sig == SIGBUS) && > - uc->context_trapno == trap_page_fault) { > - int page_size = os::vm_page_size(); > - address addr = (address) info->si_addr; > - address pc = os::Bsd::ucontext_get_pc(uc); > - // Make sure the pc and the faulting address are sane. > - // > - // If an instruction spans a page boundary, and the page containing > - // the beginning of the instruction is executable but the following > - // page is not, the pc and the faulting address might be slightly > - // different - we still want to unguard the 2nd page in this case. > - // > - // 15 bytes seems to be a (very) safe value for max instruction size. > - bool pc_is_near_addr = > - (pointer_delta((void*) addr, (void*) pc, sizeof(char)) < 15); > - bool instr_spans_page_boundary = > - (align_size_down((intptr_t) pc ^ (intptr_t) addr, > - (intptr_t) page_size) > 0); > - > - if (pc == addr || (pc_is_near_addr && instr_spans_page_boundary)) { > - static volatile address last_addr = > - (address) os::non_memory_address_word(); > - > - // In conservative mode, don't unguard unless the address is in the VM > - if (addr != last_addr && > - (UnguardOnExecutionViolation > 1 || os::address_is_in_vm(addr))) { > - > - // Unguard and retry > - address page_start = > - (address) align_size_down((intptr_t) addr, (intptr_t) page_size); > - bool res = os::unguard_memory((char*) page_start, page_size); > - > - if (PrintMiscellaneous && Verbose) { > - char buf[256]; > - jio_snprintf(buf, sizeof(buf), "Execution protection violation " > - "at " INTPTR_FORMAT > - ", unguarding " INTPTR_FORMAT ": %s, errno=%d", addr, > - page_start, (res ? "success" : "failed"), errno); > - tty->print_raw_cr(buf); > - } > - stub = pc; > - > - // Set last_addr so if we fault again at the same address, we don't end > - // up in an endless loop. > - // > - // There are two potential complications here. Two threads trapping at > - // the same address at the same time could cause one of the threads to > - // think it already unguarded, and abort the VM. Likely very rare. > - // > - // The other race involves two threads alternately trapping at > - // different addresses and failing to unguard the page, resulting in > - // an endless loop. This condition is probably even more unlikely than > - // the first. > - // > - // Although both cases could be avoided by using locks or thread local > - // last_addr, these solutions are unnecessary complication: this > - // handler is a best-effort safety net, not a complete solution. It is > - // disabled by default and should only be used as a workaround in case > - // we missed any no-execute-unsafe VM code. > - > - last_addr = addr; > - } > - } > - } > -#endif // !AMD64 > - > - if (stub != NULL) { > - // save all thread context in case we need to restore it > - if (thread != NULL) thread->set_saved_exception_pc(pc); > - > - uc->context_pc = (intptr_t)stub; > - return true; > - } > - > - // signal-chaining > - if (os::Bsd::chained_handler(sig, info, ucVoid)) { > - return true; > - } > - > - if (!abort_if_unrecognized) { > - // caller wants another chance, so give it to him > - return false; > - } > - > - if (pc == NULL && uc != NULL) { > - pc = os::Bsd::ucontext_get_pc(uc); > - } > - > - // unmask current signal > - sigset_t newset; > - sigemptyset(&newset); > - sigaddset(&newset, sig); > - sigprocmask(SIG_UNBLOCK, &newset, NULL); > - > - VMError err(t, sig, pc, info, ucVoid); > - err.report_and_die(); > - > - ShouldNotReachHere(); > } > - > #ifdef _ALLBSD_SOURCE > // From solaris_i486.s ported to bsd_i486.s > extern "C" void fixcw(); > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From glewis at eyesbeyond.com Mon Dec 22 06:16:25 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Mon, 22 Dec 2008 06:16:25 -0800 Subject: XStartOnFirstThread - Possible Patch In-Reply-To: <2C2E942F-15A0-4097-A370-421879238EA7@apple.com> References: <2C2E942F-15A0-4097-A370-421879238EA7@apple.com> Message-ID: <20081222141625.GD96610@misty.eyesbeyond.com> On Sat, Dec 20, 2008 at 03:30:13PM -0800, Mike Swingler wrote: > On Dec 2, 2008, at 7:48 PM, Michael Franz wrote: > > > Hi, > > > > Here is one way of adding -XstartOnFirstThread for OS X. I copied > > the logic from other parts of the launcher and not too sure if all > > of the code in the new ContinueInSameThread function is needed. > > Please review and comment. > > This implementation looks good. It's much simpler than our own (which > has other gunk in place for the benefit of our Cocoa/AppKit-based AWT). Thanks for taking a look Mike! Michael, I'm happy to check in this patch if you like. -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From glewis at eyesbeyond.com Mon Dec 22 06:29:17 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Mon, 22 Dec 2008 06:29:17 -0800 Subject: Native Socket Error On OS X (BSDs) In-Reply-To: References: Message-ID: <20081222142917.GE96610@misty.eyesbeyond.com> G'day Michael, On Sun, Dec 21, 2008 at 09:16:41PM -0500, Michael Franz wrote: > I have been investigating this more and been trying to figure out where > NET_Timeout is defined on OS X. It is being called in PlanSocketImpl.c. > There are two definitions that I have found, one for linux and one for bsd. > A third uses JVM_Timeout. The bsd version is specific to FreeBSD. Are > there known issues with JVM_Timeout? Why does Linux and FreeBSD need > definitions that are different from the one in Hotspot? They look very similar don't they. I wonder if the HotSpot version is actually exposed for the JDK code to use? > jdk/src/solaris/native/java/net/bsd_close.c > jdk/src/solaris/native/java/net/linux_close.c > hotspot/src/os/bsd/vm/hpi_bsd.hpp > > I changed the inline int hpi::timeout(int fd, long timeout) method to not > use the Apple specific code and I think the problem is fixed (at least for > me). So just removing the __APPLE__ code below fixes it for you? I can commit that change for you. > #ifdef __APPLE__ > // XXXDARWIN: poll() appears non-interruptable on Leopard: > Thread.interrupt() failed to > // cause interrupt. Does poll work at all on Tiger? Needs investigation. > fd_set fdset; > struct timeval seltv; > > FD_ZERO(&fdset); > FD_SET(fd, &fdset); > > seltv.tv_sec = timeout / 1000; > seltv.tv_usec = (timeout % 1000) * 1000; > > INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL, &seltv), res, > os::Bsd::clear_interrupted); > #else > struct pollfd pfd; > > pfd.fd = fd; > pfd.events = POLLIN | POLLERR; > > INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res, > os::Bsd::clear_interrupted); > #endif > > Michael > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From Dalibor.Topic at Sun.COM Mon Dec 22 06:35:14 2008 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Mon, 22 Dec 2008 15:35:14 +0100 Subject: A process question In-Reply-To: <20081222140454.GB96610@misty.eyesbeyond.com> References: <494C34F0.5030500@Sun.COM> <20081222140454.GB96610@misty.eyesbeyond.com> Message-ID: <494FA5A2.7090504@Sun.COM> On 12/22/08 15:04, Greg Lewis wrote: > G'day Xiaobin, > > On Fri, Dec 19, 2008 at 03:57:36PM -0800, Xiaobin Lu wrote: > >> While I am working a fix to make the build pass on Mac OS, I notice that >> for some files, I could go head and just check it into the open jdk 7 >> tree and let someone take care of the merge, but I am encountering one >> file that I need to change (os_bsd_x86.cpp) in order to make the 64 bit >> pass. >> >> Would someone help me clarify how the put back process we are using >> here? How can I get the check in permission etc? >> >> Thanks so much in advance! >> > > I'd be happy to check in the changes for you. I'd also be happy to help > arrange for access for you if that would be easier. I believe Dalibor > Topic can help with that. > > Yep - would you like to grant Xiaobin commit access to the BSD project? cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From mvfranz at gmail.com Mon Dec 22 06:46:26 2008 From: mvfranz at gmail.com (Michael Franz) Date: Mon, 22 Dec 2008 09:46:26 -0500 Subject: XStartOnFirstThread - Possible Patch In-Reply-To: <20081222141625.GD96610@misty.eyesbeyond.com> References: <2C2E942F-15A0-4097-A370-421879238EA7@apple.com> <20081222141625.GD96610@misty.eyesbeyond.com> Message-ID: Greg, If there is no better patch, I am happy with this one being committed. Thanks Michael On Mon, Dec 22, 2008 at 9:16 AM, Greg Lewis wrote: > On Sat, Dec 20, 2008 at 03:30:13PM -0800, Mike Swingler wrote: > > On Dec 2, 2008, at 7:48 PM, Michael Franz wrote: > > > > > Hi, > > > > > > Here is one way of adding -XstartOnFirstThread for OS X. I copied > > > the logic from other parts of the launcher and not too sure if all > > > of the code in the new ContinueInSameThread function is needed. > > > Please review and comment. > > > > This implementation looks good. It's much simpler than our own (which > > has other gunk in place for the benefit of our Cocoa/AppKit-based AWT). > > Thanks for taking a look Mike! > > Michael, I'm happy to check in this patch if you like. > > -- > Greg Lewis Email : glewis at eyesbeyond.com > Eyes Beyond Web : http://www.eyesbeyond.com > Information Technology FreeBSD : glewis at FreeBSD.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081222/38fa2f03/attachment.html From mvfranz at gmail.com Mon Dec 22 06:55:55 2008 From: mvfranz at gmail.com (Michael Franz) Date: Mon, 22 Dec 2008 09:55:55 -0500 Subject: Native Socket Error On OS X (BSDs) In-Reply-To: <20081222142917.GE96610@misty.eyesbeyond.com> References: <20081222142917.GE96610@misty.eyesbeyond.com> Message-ID: Greg, On Mon, Dec 22, 2008 at 9:29 AM, Greg Lewis wrote: > G'day Michael, > > On Sun, Dec 21, 2008 at 09:16:41PM -0500, Michael Franz wrote: > > I have been investigating this more and been trying to figure out where > > NET_Timeout is defined on OS X. It is being called in PlanSocketImpl.c. > > There are two definitions that I have found, one for linux and one for > bsd. > > A third uses JVM_Timeout. The bsd version is specific to FreeBSD. Are > > there known issues with JVM_Timeout? Why does Linux and FreeBSD need > > definitions that are different from the one in Hotspot? > Based on the fact that Solaris does not have a specific version and Linux and FreeBSD do, the HotSpot implementation should be available. It might be a good time to remove the Linux and FreeBSD version so that all the platforms use the same code. > > They look very similar don't they. I wonder if the HotSpot version is > actually exposed for the JDK code to use? > > > jdk/src/solaris/native/java/net/bsd_close.c > > jdk/src/solaris/native/java/net/linux_close.c > > hotspot/src/os/bsd/vm/hpi_bsd.hpp > > > > I changed the inline int hpi::timeout(int fd, long timeout) method to not > > use the Apple specific code and I think the problem is fixed (at least > for > > me). > Yes, just ignoring/removing the Apple specific coding seemed to fix the problem. I did not do any deep research into socket programming on OS X. Anyone with knowledge of sockets on OS X comment on the comments? Is poll on Tiger really not interruptable? > > So just removing the __APPLE__ code below fixes it for you? I can commit > that change for you. > > > #ifdef __APPLE__ > > // XXXDARWIN: poll() appears non-interruptable on Leopard: > > Thread.interrupt() failed to > > // cause interrupt. Does poll work at all on Tiger? Needs > investigation. > > fd_set fdset; > > struct timeval seltv; > > > > FD_ZERO(&fdset); > > FD_SET(fd, &fdset); > > > > seltv.tv_sec = timeout / 1000; > > seltv.tv_usec = (timeout % 1000) * 1000; > > > > INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL, &seltv), > res, > > os::Bsd::clear_interrupted); > > #else > > struct pollfd pfd; > > > > pfd.fd = fd; > > pfd.events = POLLIN | POLLERR; > > > > INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res, > > os::Bsd::clear_interrupted); > > #endif > > > > Michael > > > -- > Greg Lewis Email : glewis at eyesbeyond.com > Eyes Beyond Web : http://www.eyesbeyond.com > Information Technology FreeBSD : glewis at FreeBSD.org > Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081222/3883a432/attachment.html From Xiaobin.Lu at Sun.COM Mon Dec 22 10:30:32 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 22 Dec 2008 10:30:32 -0800 Subject: _LP64, int32_t and intptr_t In-Reply-To: <20081222135456.GA96610@misty.eyesbeyond.com> References: <38a53eb30812160556s60b3e421n8c67777eb12200a3@mail.gmail.com> <20081216165954.GA2893@misty.eyesbeyond.com> <20081222135456.GA96610@misty.eyesbeyond.com> Message-ID: <494FDCC8.2060409@Sun.COM> I have filed a bug 6787106 which cover that fix. I will put back the fix as soon as we cut off hotspt 15 tree (currently we are at hs14). I still need to put back a few bsd specific files to cover the build failures on 64 bit Mac OS as soon as I get the access permission to the tree. Thanks, -Xiaobin On 12/22/08 05:54, Greg Lewis wrote: > On Tue, Dec 16, 2008 at 08:08:37PM -0500, Michael Franz wrote: > >> What changes have you made to work around the int32_t, intptr_t problem? >> > > Attached is as far as I got before I ran into problems with the assembler > choking on stuff that wasn't changed. These aren't the right changes, but > they were the least intrusive to other code. > > BTW, can you tell me what version of as(1) you're using? Just the output > of 'as -v' would be great. > > >> On Tue, Dec 16, 2008 at 11:59 AM, Greg Lewis wrote: >> >> >>> If I can get a build going I'd be happy to cut a newer binary and put >>> it up for download. >>> >>> >> It would be nice to have a newer binary for people to try. With the patches >> that have been made the JRE can be used to run NetBeans (if the startup >> script is modified to not pass in -XDock) and IntelliJ (by using >> -Didea.no.jdk.check=true). It will not work Eclipse or SWT applications >> since we don't have an accepted patch for the -XstartOnFirstThread and there >> is now way to work around that. >> >> Michael >> > > > ------------------------------------------------------------------------ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081222/5e63919a/attachment.html From Xiaobin.Lu at Sun.COM Mon Dec 22 11:06:30 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 22 Dec 2008 11:06:30 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <20081222140953.GC96610@misty.eyesbeyond.com> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> Message-ID: <494FE536.1040102@Sun.COM> Hi Greg, I am attaching the patch to make the VM build pass on Mac OS 64 bit. Here is some explanation on the change: bytes_bsd_x86.inline.cpp: Change bswap16(x) to bswap_16(x) and the similar, I believe there was a typo for this. When some ported this to Apple platform, they missed a underscore. os_bsd_x86.cpp There was a "}" missing for 64 bit build. Other changes to make the build pass will be covered by my fix to 6787106 which I am going to put back to open JDK 7 tree soon. Please help me review the patch and feel free to let me know if there was anything wrong. -Xiaobin Greg Lewis wrote: > G'day Xiaobin, > > On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: > >> I am attaching the patch for building 64 bit VM. They are BSD specific >> files. Would someone review it and help me check it in? >> > > Sure. Can you comment a little on the changes to > src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is > bigger than the changes if that makes sense (i.e. there are some whitespace > changes due to control flow changes which are hiding those). > > -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_12_19_amd64 Type: video/x-flv Size: 1624 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081222/86f99d30/attachment.bin From landonf at plausiblelabs.com Mon Dec 22 11:26:31 2008 From: landonf at plausiblelabs.com (Landon Fuller) Date: Mon, 22 Dec 2008 11:26:31 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <494FE536.1040102@Sun.COM> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> <494FE536.1040102@Sun.COM> Message-ID: <6451F0E6-5526-4EC1-927A-B00C1E7E41A1@plausiblelabs.com> On Dec 22, 2008, at 11:06 AM, Xiaobin Lu wrote: > Hi Greg, > > I am attaching the patch to make the VM build pass on Mac OS 64 > bit. Here is some explanation on the change: > > bytes_bsd_x86.inline.cpp: > > Change bswap16(x) to bswap_16(x) and the similar, I believe there > was a typo for this. When some ported this to Apple platform, they > missed a underscore. Yes, chances are very good these are merge errors I introduced when integrating the 1.6/JRL Mac patchset. Apologies for only testing the 32-bit build. Cheers, Landon -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081222/8527747f/attachment.bin From Xiaobin.Lu at Sun.COM Mon Dec 22 14:26:49 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 22 Dec 2008 14:26:49 -0800 Subject: Native Socket Error On OS X (BSDs) In-Reply-To: References: <20081222142917.GE96610@misty.eyesbeyond.com> Message-ID: <49501429.1010200@Sun.COM> So if I understand correctly, the usage under "#ifdef __APPLE__" isn't working properly, in other words, using "select" is problematic in this case. But my question is "why using poll instead of select worked?" Thanks so much in advance for your clarification. -Xiaobin Michael Franz wrote: > Greg, > > On Mon, Dec 22, 2008 at 9:29 AM, Greg Lewis > wrote: > > G'day Michael, > > On Sun, Dec 21, 2008 at 09:16:41PM -0500, Michael Franz wrote: > > I have been investigating this more and been trying to figure > out where > > NET_Timeout is defined on OS X. It is being called in > PlanSocketImpl.c. > > There are two definitions that I have found, one for linux and > one for bsd. > > A third uses JVM_Timeout. The bsd version is specific to > FreeBSD. Are > > there known issues with JVM_Timeout? Why does Linux and FreeBSD > need > > definitions that are different from the one in Hotspot? > > > Based on the fact that Solaris does not have a specific version and > Linux and FreeBSD do, the HotSpot implementation should be available. > It might be a good time to remove the Linux and FreeBSD version so > that all the platforms use the same code. > > > > They look very similar don't they. I wonder if the HotSpot version is > actually exposed for the JDK code to use? > > > jdk/src/solaris/native/java/net/bsd_close.c > > jdk/src/solaris/native/java/net/linux_close.c > > hotspot/src/os/bsd/vm/hpi_bsd.hpp > > > > I changed the inline int hpi::timeout(int fd, long timeout) > method to not > > use the Apple specific code and I think the problem is fixed (at > least for > > me). > > > Yes, just ignoring/removing the Apple specific coding seemed to fix > the problem. > > I did not do any deep research into socket programming on OS X. > Anyone with knowledge of sockets on OS X comment on the comments? Is > poll on Tiger really not interruptable? > > > > So just removing the __APPLE__ code below fixes it for you? I can > commit > that change for you. > > > #ifdef __APPLE__ > > // XXXDARWIN: poll() appears non-interruptable on Leopard: > > Thread.interrupt() failed to > > // cause interrupt. Does poll work at all on Tiger? Needs > investigation. > > fd_set fdset; > > struct timeval seltv; > > > > FD_ZERO(&fdset); > > FD_SET(fd, &fdset); > > > > seltv.tv_sec = timeout / 1000; > > seltv.tv_usec = (timeout % 1000) * 1000; > > > > INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL, > &seltv), res, > > os::Bsd::clear_interrupted); > > #else > > struct pollfd pfd; > > > > pfd.fd = fd; > > pfd.events = POLLIN | POLLERR; > > > > INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res, > > os::Bsd::clear_interrupted); > > #endif > > > > Michael > > > -- > Greg Lewis Email : > glewis at eyesbeyond.com > Eyes Beyond Web : > http://www.eyesbeyond.com > Information Technology FreeBSD : glewis at FreeBSD.org > > Michael > ------------------------------------------------------------------------ > > > From mvfranz at gmail.com Mon Dec 22 20:30:05 2008 From: mvfranz at gmail.com (Michael Franz) Date: Mon, 22 Dec 2008 23:30:05 -0500 Subject: Native Socket Error On OS X (BSDs) In-Reply-To: <49501429.1010200@Sun.COM> References: <20081222142917.GE96610@misty.eyesbeyond.com> <49501429.1010200@Sun.COM> Message-ID: Xiaobin, By not using the APPLE specific code the connections work. The reason the select does not is that there is an invalid argument being passed to it. The invalid argument is a -1 for the time out. I assume that a -1 to poll is valid parameter and it just works. Michael On Mon, Dec 22, 2008 at 5:26 PM, Xiaobin Lu wrote: > So if I understand correctly, the usage under "#ifdef __APPLE__" isn't > working properly, in other words, using "select" is problematic in this > case. But my question is "why using poll instead of select worked?" > > Thanks so much in advance for your clarification. > > -Xiaobin > > Michael Franz wrote: > >> Greg, >> >> >> On Mon, Dec 22, 2008 at 9:29 AM, Greg Lewis > glewis at eyesbeyond.com>> wrote: >> >> G'day Michael, >> >> On Sun, Dec 21, 2008 at 09:16:41PM -0500, Michael Franz wrote: >> > I have been investigating this more and been trying to figure >> out where >> > NET_Timeout is defined on OS X. It is being called in >> PlanSocketImpl.c. >> > There are two definitions that I have found, one for linux and >> one for bsd. >> > A third uses JVM_Timeout. The bsd version is specific to >> FreeBSD. Are >> > there known issues with JVM_Timeout? Why does Linux and FreeBSD >> need >> > definitions that are different from the one in Hotspot? >> >> >> Based on the fact that Solaris does not have a specific version and Linux >> and FreeBSD do, the HotSpot implementation should be available. It might be >> a good time to remove the Linux and FreeBSD version so that all the >> platforms use the same code. >> >> >> They look very similar don't they. I wonder if the HotSpot version is >> actually exposed for the JDK code to use? >> >> > jdk/src/solaris/native/java/net/bsd_close.c >> > jdk/src/solaris/native/java/net/linux_close.c >> > hotspot/src/os/bsd/vm/hpi_bsd.hpp >> > >> > I changed the inline int hpi::timeout(int fd, long timeout) >> method to not >> > use the Apple specific code and I think the problem is fixed (at >> least for >> > me). >> >> >> Yes, just ignoring/removing the Apple specific coding seemed to fix the >> problem. >> I did not do any deep research into socket programming on OS X. Anyone >> with knowledge of sockets on OS X comment on the comments? Is poll on Tiger >> really not interruptable? >> >> >> So just removing the __APPLE__ code below fixes it for you? I can >> commit >> that change for you. >> >> > #ifdef __APPLE__ >> > // XXXDARWIN: poll() appears non-interruptable on Leopard: >> > Thread.interrupt() failed to >> > // cause interrupt. Does poll work at all on Tiger? Needs >> investigation. >> > fd_set fdset; >> > struct timeval seltv; >> > >> > FD_ZERO(&fdset); >> > FD_SET(fd, &fdset); >> > >> > seltv.tv_sec = timeout / 1000; >> > seltv.tv_usec = (timeout % 1000) * 1000; >> > >> > INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, NULL, >> &seltv), res, >> > os::Bsd::clear_interrupted); >> > #else >> > struct pollfd pfd; >> > >> > pfd.fd = fd; >> > pfd.events = POLLIN | POLLERR; >> > >> > INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res, >> > os::Bsd::clear_interrupted); >> > #endif >> > >> > Michael >> > >> -- >> Greg Lewis Email : >> glewis at eyesbeyond.com >> Eyes Beyond Web : >> http://www.eyesbeyond.com >> Information Technology FreeBSD : glewis at FreeBSD.org >> >> Michael >> ------------------------------------------------------------------------ >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081222/ec221b51/attachment.html From Xiaobin.Lu at Sun.COM Tue Dec 23 10:20:27 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 23 Dec 2008 10:20:27 -0800 Subject: Native Socket Error On OS X (BSDs) In-Reply-To: References: <20081222142917.GE96610@misty.eyesbeyond.com> <49501429.1010200@Sun.COM> Message-ID: <49512BEB.8030701@Sun.COM> Michael, Thanks for your investigation on this. So instead of removing the Apple specific code, can we just detect the "-1" argument and pass "NULL" to select as the last argument which has equivalent meaning as "-1" to "poll"? I think that might be a safer fix than just removing that code. My 2 cents. -Xiaobin On 12/22/08 20:30, Michael Franz wrote: > Xiaobin, > > By not using the APPLE specific code the connections work. The reason > the select does not is that there is an invalid argument being passed > to it. The invalid argument is a -1 for the time out. > > I assume that a -1 to poll is valid parameter and it just works. > > Michael > On Mon, Dec 22, 2008 at 5:26 PM, Xiaobin Lu > wrote: > > So if I understand correctly, the usage under "#ifdef __APPLE__" > isn't working properly, in other words, using "select" is > problematic in this case. But my question is "why using poll > instead of select worked?" > > Thanks so much in advance for your clarification. > > -Xiaobin > > Michael Franz wrote: > > Greg, > > > On Mon, Dec 22, 2008 at 9:29 AM, Greg Lewis > > >> > wrote: > > G'day Michael, > > On Sun, Dec 21, 2008 at 09:16:41PM -0500, Michael Franz wrote: > > I have been investigating this more and been trying to figure > out where > > NET_Timeout is defined on OS X. It is being called in > PlanSocketImpl.c. > > There are two definitions that I have found, one for > linux and > one for bsd. > > A third uses JVM_Timeout. The bsd version is specific to > FreeBSD. Are > > there known issues with JVM_Timeout? Why does Linux and > FreeBSD > need > > definitions that are different from the one in Hotspot? > > > Based on the fact that Solaris does not have a specific > version and Linux and FreeBSD do, the HotSpot implementation > should be available. It might be a good time to remove the > Linux and FreeBSD version so that all the platforms use the > same code. > > > They look very similar don't they. I wonder if the HotSpot > version is > actually exposed for the JDK code to use? > > > jdk/src/solaris/native/java/net/bsd_close.c > > jdk/src/solaris/native/java/net/linux_close.c > > hotspot/src/os/bsd/vm/hpi_bsd.hpp > > > > I changed the inline int hpi::timeout(int fd, long timeout) > method to not > > use the Apple specific code and I think the problem is > fixed (at > least for > > me). > > > Yes, just ignoring/removing the Apple specific coding seemed > to fix the problem. > I did not do any deep research into socket programming on OS > X. Anyone with knowledge of sockets on OS X comment on the > comments? Is poll on Tiger really not interruptable? > > > So just removing the __APPLE__ code below fixes it for you? > I can > commit > that change for you. > > > #ifdef __APPLE__ > > // XXXDARWIN: poll() appears non-interruptable on > Leopard: > > Thread.interrupt() failed to > > // cause interrupt. Does poll work at all on Tiger? Needs > investigation. > > fd_set fdset; > > struct timeval seltv; > > > > FD_ZERO(&fdset); > > FD_SET(fd, &fdset); > > > > seltv.tv_sec = timeout / 1000; > > seltv.tv_usec = (timeout % 1000) * 1000; > > > > INTERRUPTIBLE_NORESTART(::select(fd+1, &fdset, NULL, > NULL, > &seltv), res, > > os::Bsd::clear_interrupted); > > #else > > struct pollfd pfd; > > > > pfd.fd = fd; > > pfd.events = POLLIN | POLLERR; > > > > INTERRUPTIBLE_NORESTART(::poll(&pfd, 1, timeout), res, > > os::Bsd::clear_interrupted); > > #endif > > > > Michael > > > -- > Greg Lewis Email : > glewis at eyesbeyond.com > > > > Eyes Beyond Web : > http://www.eyesbeyond.com > Information Technology FreeBSD : > glewis at FreeBSD.org > > Michael > ------------------------------------------------------------------------ > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081223/e6bc3db6/attachment.html From mvfranz at gmail.com Tue Dec 23 10:54:08 2008 From: mvfranz at gmail.com (Michael Franz) Date: Tue, 23 Dec 2008 13:54:08 -0500 Subject: Native Socket Error On OS X (BSDs) In-Reply-To: <49512BEB.8030701@Sun.COM> References: <20081222142917.GE96610@misty.eyesbeyond.com> <49501429.1010200@Sun.COM> <49512BEB.8030701@Sun.COM> Message-ID: Xiaobin, I would rather determine if the comments are correct or not. // XXXDARWIN: poll() appears non-interruptable on Leopard: Thread.interrupt() failed to // cause interrupt. Does poll work at all on Tiger? Needs investigation. I am interested in why Linux and FreeBSD cannot use this code. If we can have the same code for all platforms it will be easier to maintain. Michael On Tue, Dec 23, 2008 at 1:20 PM, Xiaobin Lu wrote: > Michael, > > Thanks for your investigation on this. So instead of removing the Apple > specific code, can we just detect the "-1" argument and pass "NULL" to > select as the last argument which has equivalent meaning as "-1" to "poll"? > I think that might be a safer fix than just removing that code. > > My 2 cents. > > -Xiaobin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081223/db48569e/attachment.html From Xiaobin.Lu at Sun.COM Tue Dec 23 14:07:27 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 23 Dec 2008 14:07:27 -0800 Subject: Native Socket Error On OS X (BSDs) In-Reply-To: References: <20081222142917.GE96610@misty.eyesbeyond.com> <49501429.1010200@Sun.COM> <49512BEB.8030701@Sun.COM> Message-ID: <4951611F.5040008@Sun.COM> Hi Michael, I agree with you that we should understand why the comments are there and whether it is correct. I am also wondering whether we should remove the interruptible I/O support completely. The interruptible I/O is only supported on Solaris and recently we switch the flag UseVMInterruptibleIO to false by default for JDK 7 (bug 6554406 & 6382902). But it is probably a good idea to remove that support since that will get rid of many confusions around. There was a discussions around whether we should use "select" over "poll" in general and the past experience told us "poll" performs better and "select" is problematic and can result in very odd failures if you have file handle numbers that exceed the bitmap capacity. Plus, on some systems select is emulated via poll. Regards, -Xiaobin On 12/23/08 10:54, Michael Franz wrote: > Xiaobin, > > I would rather determine if the comments are correct or not. > // XXXDARWIN: poll() appears non-interruptable on Leopard: > Thread.interrupt() failed to > // cause interrupt. Does poll work at all on Tiger? Needs > investigation. > > I am interested in why Linux and FreeBSD cannot use this code. > If we can have the same code for all platforms it will be easier to > maintain. > > Michael > > On Tue, Dec 23, 2008 at 1:20 PM, Xiaobin Lu > wrote: > > Michael, > > Thanks for your investigation on this. So instead of removing the > Apple specific code, can we just detect the "-1" argument and pass > "NULL" to select as the last argument which has equivalent meaning > as "-1" to "poll"? I think that might be a safer fix than just > removing that code. > > My 2 cents. > > -Xiaobin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081223/b8276e0f/attachment.html From kurt at intricatesoftware.com Tue Dec 23 14:37:37 2008 From: kurt at intricatesoftware.com (Kurt Miller) Date: Tue, 23 Dec 2008 17:37:37 -0500 Subject: Native Socket Error On OS X (BSDs) In-Reply-To: <4951611F.5040008@Sun.COM> References: <20081222142917.GE96610@misty.eyesbeyond.com> <49501429.1010200@Sun.COM> <49512BEB.8030701@Sun.COM> <4951611F.5040008@Sun.COM> Message-ID: <49516831.9000506@intricatesoftware.com> Hi Xiaobin, I noticed your comment about removing InterruptibleIO support from the BSD port. I think that is a good idea. It is one of the areas where I diverged from the Linux code base a bit to bring it in. Removing it will make the BSD closer to the Linux code base and further reduce the bsd-port divergence. I'll look into that after I get synced up and merge in some other changes I'm working on now. Regards, -Kurt Xiaobin Lu wrote: > Hi Michael, > > I agree with you that we should understand why the comments are there > and whether it is correct. I am also wondering whether we should remove > the interruptible I/O support completely. The interruptible I/O is only > supported on Solaris and recently we switch the flag > UseVMInterruptibleIO to false by default for JDK 7 (bug 6554406 & > 6382902). But it is probably a good idea to remove that support since > that will get rid of many confusions around. > > There was a discussions around whether we should use "select" over > "poll" in general and the past experience told us "poll" performs better > and "select" is problematic and can result in very odd failures if you > have file handle numbers that exceed the bitmap capacity. Plus, on some > systems select is emulated via poll. > > Regards, > -Xiaobin > > On 12/23/08 10:54, Michael Franz wrote: >> Xiaobin, >> >> I would rather determine if the comments are correct or not. >> // XXXDARWIN: poll() appears non-interruptable on Leopard: >> Thread.interrupt() failed to >> // cause interrupt. Does poll work at all on Tiger? Needs >> investigation. >> >> I am interested in why Linux and FreeBSD cannot use this code. >> If we can have the same code for all platforms it will be easier to >> maintain. >> >> Michael >> >> On Tue, Dec 23, 2008 at 1:20 PM, Xiaobin Lu > > wrote: >> >> Michael, >> >> Thanks for your investigation on this. So instead of removing the >> Apple specific code, can we just detect the "-1" argument and pass >> "NULL" to select as the last argument which has equivalent meaning >> as "-1" to "poll"? I think that might be a safer fix than just >> removing that code. >> >> My 2 cents. >> >> -Xiaobin >> >> >> > > > ------------------------------------------------------------------------ > > From glewis at eyesbeyond.com Thu Dec 25 23:24:29 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Thu, 25 Dec 2008 23:24:29 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <494FE536.1040102@Sun.COM> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> <494FE536.1040102@Sun.COM> Message-ID: <20081226072429.GA69479@misty.eyesbeyond.com> G'day Xiaobin, On Mon, Dec 22, 2008 at 11:06:30AM -0800, Xiaobin Lu wrote: > I am attaching the patch to make the VM build pass on Mac OS 64 bit. > Here is some explanation on the change: > > bytes_bsd_x86.inline.cpp: > > Change bswap16(x) to bswap_16(x) and the similar, I believe there was a > typo for this. When some ported this to Apple platform, they missed a > underscore. > > os_bsd_x86.cpp > > There was a "}" missing for 64 bit build. Thats a lot clearer when I use diff -b :). > Other changes to make the build pass will be covered by my fix to > 6787106 which I am going to put back to open JDK 7 tree soon. > > Please help me review the patch and feel free to let me know if there > was anything wrong. Looks good to me -- I say go ahead and commit it. > Greg Lewis wrote: > > G'day Xiaobin, > > > > On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: > > > >> I am attaching the patch for building 64 bit VM. They are BSD specific > >> files. Would someone review it and help me check it in? > >> > > > > Sure. Can you comment a little on the changes to > > src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is > > bigger than the changes if that makes sense (i.e. there are some whitespace > > changes due to control flow changes which are hiding those). > > > > > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From Xiaobin.Lu at Sun.COM Thu Dec 25 23:34:58 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Thu, 25 Dec 2008 23:34:58 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <20081226072429.GA69479@misty.eyesbeyond.com> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> <494FE536.1040102@Sun.COM> <20081226072429.GA69479@misty.eyesbeyond.com> Message-ID: <49548922.80703@Sun.COM> Hi Greg, So with my openjdk id, I can commit the changes without extra permission? Thanks, -Xiaobin Greg Lewis wrote: > G'day Xiaobin, > > On Mon, Dec 22, 2008 at 11:06:30AM -0800, Xiaobin Lu wrote: > >> I am attaching the patch to make the VM build pass on Mac OS 64 bit. >> Here is some explanation on the change: >> >> bytes_bsd_x86.inline.cpp: >> >> Change bswap16(x) to bswap_16(x) and the similar, I believe there was a >> typo for this. When some ported this to Apple platform, they missed a >> underscore. >> >> os_bsd_x86.cpp >> >> There was a "}" missing for 64 bit build. >> > > Thats a lot clearer when I use diff -b :). > > >> Other changes to make the build pass will be covered by my fix to >> 6787106 which I am going to put back to open JDK 7 tree soon. >> >> Please help me review the patch and feel free to let me know if there >> was anything wrong. >> > > Looks good to me -- I say go ahead and commit it. > > >> Greg Lewis wrote: >> >>> G'day Xiaobin, >>> >>> On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: >>> >>> >>>> I am attaching the patch for building 64 bit VM. They are BSD specific >>>> files. Would someone review it and help me check it in? >>>> >>>> >>> Sure. Can you comment a little on the changes to >>> src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is >>> bigger than the changes if that makes sense (i.e. there are some whitespace >>> changes due to control flow changes which are hiding those). >>> >>> >>> > > > > From glewis at eyesbeyond.com Fri Dec 26 09:27:36 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Fri, 26 Dec 2008 09:27:36 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <49548922.80703@Sun.COM> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> <494FE536.1040102@Sun.COM> <20081226072429.GA69479@misty.eyesbeyond.com> <49548922.80703@Sun.COM> Message-ID: <20081226172736.GA42840@misty.eyesbeyond.com> G'day Xiaobin, On Thu, Dec 25, 2008 at 11:34:58PM -0800, Xiaobin Lu wrote: > So with my openjdk id, I can commit the changes without extra permission? I think I should have looked harder at the change first, sorry. I tried compiling with that change in and it broke the i386 build :(. I'm looking at things side by side with the current Linux code to try and get the braces and #ifdef's right, but I have to say this part of the code is becoming quite confusing with the proliferation of preprocessor conditionals. I hope to have something later today that you can test on Mac OS X. > Greg Lewis wrote: > > G'day Xiaobin, > > > > On Mon, Dec 22, 2008 at 11:06:30AM -0800, Xiaobin Lu wrote: > > > >> I am attaching the patch to make the VM build pass on Mac OS 64 bit. > >> Here is some explanation on the change: > >> > >> bytes_bsd_x86.inline.cpp: > >> > >> Change bswap16(x) to bswap_16(x) and the similar, I believe there was a > >> typo for this. When some ported this to Apple platform, they missed a > >> underscore. > >> > >> os_bsd_x86.cpp > >> > >> There was a "}" missing for 64 bit build. > >> > > > > Thats a lot clearer when I use diff -b :). > > > > > >> Other changes to make the build pass will be covered by my fix to > >> 6787106 which I am going to put back to open JDK 7 tree soon. > >> > >> Please help me review the patch and feel free to let me know if there > >> was anything wrong. > >> > > > > Looks good to me -- I say go ahead and commit it. > > > > > >> Greg Lewis wrote: > >> > >>> G'day Xiaobin, > >>> > >>> On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: > >>> > >>> > >>>> I am attaching the patch for building 64 bit VM. They are BSD specific > >>>> files. Would someone review it and help me check it in? > >>>> > >>>> > >>> Sure. Can you comment a little on the changes to > >>> src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is > >>> bigger than the changes if that makes sense (i.e. there are some whitespace > >>> changes due to control flow changes which are hiding those). > >>> > >>> > >>> > > > > > > > > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From glewis at eyesbeyond.com Fri Dec 26 17:05:32 2008 From: glewis at eyesbeyond.com (glewis at eyesbeyond.com) Date: Sat, 27 Dec 2008 01:05:32 +0000 Subject: hg: bsd-port/bsd-port: 6 new changesets Message-ID: <20081227010533.19AD1DF78@hg.openjdk.java.net> Changeset: 541bdc5ad32f Author: ohair Date: 2008-12-01 15:28 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/rev/541bdc5ad32f 6750229: Upgrade Recommended Linux and Windows Build OS Reviewed-by: xdono ! README-builds.html Changeset: a20db75d7f33 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/rev/a20db75d7f33 Added tag jdk7-b41 for changeset 541bdc5ad32f ! .hgtags Changeset: 60aab86966e9 Author: ohair Date: 2008-12-05 17:18 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/rev/60aab86966e9 6781784: Fix ant link in build readme Reviewed-by: michaelm ! README-builds.html Changeset: 94052b872873 Author: xdono Date: 2008-12-15 10:24 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/rev/94052b872873 Merge Changeset: 848e684279d2 Author: xdono Date: 2008-12-18 21:33 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/rev/848e684279d2 Added tag jdk7-b42 for changeset 94052b872873 ! .hgtags Changeset: 310ab698eb58 Author: glewis at misty.eyesbeyond.com Date: 2008-12-25 23:41 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/rev/310ab698eb58 . Merge with the main OpenJDK repositor From glewis at eyesbeyond.com Fri Dec 26 17:06:46 2008 From: glewis at eyesbeyond.com (glewis at eyesbeyond.com) Date: Sat, 27 Dec 2008 01:06:46 +0000 Subject: hg: bsd-port/bsd-port/corba: 4 new changesets Message-ID: <20081227010650.25676DF79@hg.openjdk.java.net> Changeset: d9a0ca94dcf8 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/d9a0ca94dcf8 Added tag jdk7-b41 for changeset c90eeda9594e ! .hgtags Changeset: ccd6a16502e0 Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/ccd6a16502e0 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk Changeset: 9cd740d48a48 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/9cd740d48a48 Added tag jdk7-b42 for changeset ccd6a16502e0 ! .hgtags Changeset: 75576a3af8a1 Author: glewis at misty.eyesbeyond.com Date: 2008-12-26 08:48 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/corba/rev/75576a3af8a1 . Merge with the main OpenJDK repository From glewis at eyesbeyond.com Fri Dec 26 17:08:37 2008 From: glewis at eyesbeyond.com (glewis at eyesbeyond.com) Date: Sat, 27 Dec 2008 01:08:37 +0000 Subject: hg: bsd-port/bsd-port/jaxp: 3 new changesets Message-ID: <20081227010842.1EFAFDF7E@hg.openjdk.java.net> Changeset: 036e0dca841a Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jaxp/rev/036e0dca841a Added tag jdk7-b41 for changeset 0758bd3e2852 ! .hgtags Changeset: 96fe28d4a913 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jaxp/rev/96fe28d4a913 Added tag jdk7-b42 for changeset 036e0dca841a ! .hgtags Changeset: 4219c9315d88 Author: glewis at misty.eyesbeyond.com Date: 2008-12-26 08:48 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jaxp/rev/4219c9315d88 . Merge with the main OpenJDK repository From glewis at eyesbeyond.com Fri Dec 26 17:10:27 2008 From: glewis at eyesbeyond.com (glewis at eyesbeyond.com) Date: Sat, 27 Dec 2008 01:10:27 +0000 Subject: hg: bsd-port/bsd-port/jaxws: 3 new changesets Message-ID: <20081227011032.26BA1DF85@hg.openjdk.java.net> Changeset: 621c02d83abc Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jaxws/rev/621c02d83abc Added tag jdk7-b41 for changeset a8379d24aa03 ! .hgtags Changeset: 1ad2f51564db Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jaxws/rev/1ad2f51564db Added tag jdk7-b42 for changeset 621c02d83abc ! .hgtags Changeset: ce58f65807b2 Author: glewis at misty.eyesbeyond.com Date: 2008-12-26 08:48 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jaxws/rev/ce58f65807b2 . Merge with the main OpenJDK repository From glewis at eyesbeyond.com Fri Dec 26 17:12:20 2008 From: glewis at eyesbeyond.com (glewis at eyesbeyond.com) Date: Sat, 27 Dec 2008 01:12:20 +0000 Subject: hg: bsd-port/bsd-port/langtools: 11 new changesets Message-ID: <20081227011237.69D20DF8A@hg.openjdk.java.net> Changeset: 1d4f01925bd0 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/1d4f01925bd0 Added tag jdk7-b41 for changeset ded6b40f558e ! .hgtags Changeset: 1d1f34b36535 Author: mcimadamore Date: 2008-11-26 11:07 +0000 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/1d1f34b36535 6776289: Regression: javac7 doesnt resolve method calls properly Summary: Superclass' private methods shouldn't be considered during method resolution Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/generics/6711619/T6711619a.out + test/tools/javac/overload/T6776289.java Changeset: 6210fb7e7544 Author: jjg Date: 2008-12-01 12:15 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/6210fb7e7544 6778493: Fix (langtools) ant build to honor fcs MILESTONE setting Reviewed-by: ohair Contributed-by: mjw at redhat.com ! make/Makefile Changeset: 4674298aaf3b Author: tbell Date: 2008-12-05 09:52 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/4674298aaf3b Merge Changeset: fdfed22db054 Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/fdfed22db054 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/javac/comp/Todo.java ! src/share/classes/com/sun/tools/javac/util/JavacMessages.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/Main.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/javax/tools/FileObject.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/lib/JavadocTester.java ! test/com/sun/javadoc/testSupplementary/TestSupplementary.java ! test/tools/apt/Basics/print.sh ! test/tools/apt/Compile/compile.sh ! test/tools/apt/Discovery/discovery.sh ! test/tools/apt/mirror/declaration/AnnoMirror.java ! test/tools/apt/mirror/declaration/AnnoTypeDecl.java ! test/tools/apt/mirror/declaration/AnnoTypeElemDecl.java ! test/tools/apt/mirror/declaration/AnnoVal.java ! test/tools/apt/mirror/declaration/ClassDecl.java ! test/tools/apt/mirror/declaration/ConstExpr.java ! test/tools/apt/mirror/declaration/ConstructorDecl.java ! test/tools/apt/mirror/declaration/EnumDecl.java ! test/tools/apt/mirror/declaration/FieldDecl.java ! test/tools/apt/mirror/declaration/GetAnno.java ! test/tools/apt/mirror/declaration/InterfaceDecl.java ! test/tools/apt/mirror/declaration/MethodDecl.java ! test/tools/apt/mirror/declaration/PackageDecl.java ! test/tools/apt/mirror/declaration/ParameterDecl.java ! test/tools/apt/mirror/type/AnnoTyp.java ! test/tools/apt/mirror/type/ArrayTyp.java ! test/tools/apt/mirror/type/ClassTyp.java ! test/tools/apt/mirror/type/EnumTyp.java ! test/tools/apt/mirror/type/InterfaceTyp.java ! test/tools/apt/mirror/type/PrimitiveTyp.java ! test/tools/apt/mirror/type/TypeVar.java ! test/tools/apt/mirror/type/WildcardTyp.java ! test/tools/apt/mirror/util/Overrides.java ! test/tools/apt/mirror/util/TypeCreation.java ! test/tools/javac/6457284/T6457284.java ! test/tools/javac/links/T.java ! test/tools/javac/links/links.sh ! test/tools/javac/policy/test1/A.java ! test/tools/javac/policy/test1/D.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/processing/6348193/T6348193.java ! test/tools/javadoc/BooleanConst.java ! test/tools/javadoc/BreakIteratorWarning.java ! test/tools/javadoc/FlagsTooEarly.java ! test/tools/javadoc/InlineTagsWithBraces.java ! test/tools/javadoc/LangVers.java ! test/tools/javadoc/MethodLinks.java ! test/tools/javadoc/NoStar.java ! test/tools/javadoc/T4994049/T4994049.java ! test/tools/javadoc/XWerror.java ! test/tools/javadoc/completionFailure/CompletionFailure.java ! test/tools/javadoc/dupOk/DupOk.java ! test/tools/javadoc/imports/MissingImport.java ! test/tools/javadoc/lib/Tester.java ! test/tools/javadoc/nestedClass/NestedClass.java ! test/tools/javadoc/sourceOnly/p/SourceOnly.java ! test/tools/javadoc/sourceOption/SourceOption.java ! test/tools/javadoc/subpackageIgnore/SubpackageIgnore.java Changeset: 5e5567c2db56 Author: xdono Date: 2008-12-15 17:13 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/5e5567c2db56 Merge Changeset: b044af4939c9 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/b044af4939c9 Added tag jdk7-b42 for changeset 5e5567c2db56 ! .hgtags Changeset: 8db0c5fd6e99 Author: jjg Date: 2008-12-02 14:35 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/8db0c5fd6e99 6778638: javadoc regression tests require tabs Reviewed-by: darcy ! test/com/sun/javadoc/testSourceTab/DoubleTab/C.java ! test/com/sun/javadoc/testSourceTab/SingleTab/C.java ! test/com/sun/javadoc/testSourceTab/TestSourceTab.java Changeset: 4efd44aa85ff Author: tbell Date: 2008-12-05 21:59 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/4efd44aa85ff Merge Changeset: e2f8f6daee9d Author: tbell Date: 2008-12-19 10:39 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/e2f8f6daee9d Merge Changeset: 8d593ecfa615 Author: glewis at misty.eyesbeyond.com Date: 2008-12-26 08:48 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/langtools/rev/8d593ecfa615 . Merge with the main OpenJDK repository From glewis at eyesbeyond.com Fri Dec 26 17:25:30 2008 From: glewis at eyesbeyond.com (glewis at eyesbeyond.com) Date: Sat, 27 Dec 2008 01:25:30 +0000 Subject: hg: bsd-port/bsd-port/jdk: 41 new changesets Message-ID: <20081227013322.A5A78DF95@hg.openjdk.java.net> Changeset: b213ea31bcb3 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/b213ea31bcb3 Added tag jdk7-b41 for changeset 44941f893cea ! .hgtags Changeset: 4f985ba72055 Author: sherman Date: 2008-11-19 14:29 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/4f985ba72055 6714428: 'os.name' system property shows wrong value on 64-bit Windows XP Summary: update to detect the correct os.name for 64-bit XP Reviewed-by: darcy ! src/windows/native/java/lang/java_props_md.c Changeset: 098e456e860e Author: emcmanus Date: 2008-11-20 10:10 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/098e456e860e 6772779: @NotificationInfo does not create MBeanNotificationInfo in the MBean's MBeanInfo 6773593: CompositeDataSupport constructor javadoc is not in sync with the implementation Reviewed-by: sjiang ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/openmbean/CompositeDataSupport.java ! test/javax/management/Introspector/AnnotatedNotificationInfoTest.java Changeset: 9df22bc448a3 Author: sherman Date: 2008-11-20 14:06 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/9df22bc448a3 6745216: missing 4 chraset aliases in sun.nio.cs package Summary: added "834" into x-IBM834's aliase list. Reviewed-by: alanb ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java Changeset: 97e2e87aa035 Author: dfuchs Date: 2008-11-21 18:18 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/97e2e87aa035 6774170: LocalRMIServerSocketFactory should protect against ServerSocket.accept().getInetAddress() being null Reviewed-by: emcmanus, jfdenise ! src/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java + test/sun/management/jmxremote/LocalRMIServerSocketFactoryTest.java Changeset: ce2d0938ea27 Author: tbell Date: 2008-11-21 20:53 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/ce2d0938ea27 Merge Changeset: d7b0a715bd3b Author: martin Date: 2008-11-23 09:56 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/d7b0a715bd3b 6775152: freetype version check program problem main arg order Summary: Fix all compiler warnings Reviewed-by: ohair, tbell ! make/common/shared/Sanity.gmk Changeset: 31cb1c17f524 Author: mullan Date: 2008-11-25 10:17 -0500 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/31cb1c17f524 6728890: Add SwissSign root certificates to the JDK 6732157: Add VeriSign TSA Root Cert to the JDK 6754779: Add Camerfirma root certificates to the JDK 6768559: Add t-systems root CA certificate (Deutsche Telekom Root CA 2) to the JRE Reviewed-by: vinnie ! test/lib/security/cacerts/VerifyCACerts.java Changeset: b1620482689a Author: sherman Date: 2008-11-25 10:09 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/b1620482689a 6774710: spp.sh used by genBasic.sh/genCopyDirectMemory.sh Summary: update the scripts to use java version of spp Reviewed-by: alanb ! test/java/nio/Buffer/genBasic.sh ! test/java/nio/Buffer/genCopyDirectMemory.sh Changeset: b7c47f49a53d Author: alanb Date: 2008-11-25 19:26 +0000 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/b7c47f49a53d 6593946: (bf) X-Buffer.compact() does not discard mark as specified Summary: InvalidMarkException now correctly thrown. Thanks to keiths at redhat.com for the bug report and initial fix. Reviewed-by: sherman, darcy ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/ByteBufferAs-X-Buffer.java ! src/share/classes/java/nio/Direct-X-Buffer.java ! src/share/classes/java/nio/Heap-X-Buffer.java ! test/java/nio/Buffer/Basic-X.java ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/Buffer/genBasic.sh Changeset: a0709a172b6d Author: chegar Date: 2008-11-26 15:37 +0000 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/a0709a172b6d 6720866: Slow performance using HttpURLConnection for upload Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/ChunkedOutputStream.java Changeset: 24a31530683d Author: emcmanus Date: 2008-11-27 15:44 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/24a31530683d 6776225: JMX.isNotificationSource wrong when DynamicWrapperMBean + SendNotification injection Reviewed-by: dfuchs, jfdenise ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/StandardEmitterMBean.java ! src/share/classes/javax/management/StandardMBean.java ! test/javax/management/MBeanServer/DynamicWrapperMBeanTest.java Changeset: 3d110bb4dc19 Author: sherman Date: 2008-11-29 20:55 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3d110bb4dc19 6725399: (ch) Channels.newInputStream should check for null Summary: update to check null arg for all Channels methods Reviewed-by: alanb ! src/share/classes/java/nio/channels/Channels.java ! test/java/nio/channels/Channels/Basic.java Changeset: d782143219d6 Author: tbell Date: 2008-12-05 09:51 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/d782143219d6 Merge Changeset: 3ef0bdfa7609 Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3ef0bdfa7609 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! make/javax/swing/Makefile ! make/netbeans/jmx/build.xml ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/Makefile ! src/share/classes/com/sun/java/swing/SwingUtilities3.java ! src/share/classes/com/sun/java/swing/plaf/windows/DesktopProperty.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameTitlePane.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsScrollBarUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTabbedPaneUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java ! src/share/classes/com/sun/jmx/defaults/ServiceName.java ! src/share/classes/com/sun/jmx/mbeanserver/ClassLoaderRepositorySupport.java ! src/share/classes/com/sun/jmx/mbeanserver/ObjectInputStreamWithLoader.java ! src/share/classes/com/sun/jmx/mbeanserver/SecureClassLoaderRepository.java ! src/share/classes/com/sun/jmx/mbeanserver/WeakIdentityHashMap.java ! src/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/share/classes/com/sun/jmx/remote/internal/Unmarshal.java ! src/share/classes/com/sun/jmx/remote/util/ClassLoaderWithRepository.java ! src/share/classes/com/sun/jmx/remote/util/ClassLogger.java ! src/share/classes/com/sun/jmx/remote/util/OrderClassLoaders.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/nio/Buffer.java ! src/share/classes/java/nio/channels/SelectableChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java ! src/share/classes/java/text/SimpleDateFormat.java ! src/share/classes/javax/management/ClientContext.java ! src/share/classes/javax/management/DefaultLoaderRepository.java ! src/share/classes/javax/management/JMRuntimeException.java ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanInfo.java ! src/share/classes/javax/management/Notification.java ! src/share/classes/javax/management/NotificationListener.java ! src/share/classes/javax/management/loading/DefaultLoaderRepository.java ! src/share/classes/javax/management/loading/MLetObjectInputStream.java ! src/share/classes/javax/management/modelmbean/ModelMBeanInfo.java ! src/share/classes/javax/management/openmbean/OpenMBeanParameterInfoSupport.java ! src/share/classes/javax/management/relation/MBeanServerNotificationFilter.java ! src/share/classes/javax/management/relation/Role.java ! src/share/classes/javax/management/relation/RoleList.java ! src/share/classes/javax/management/relation/RoleResult.java ! src/share/classes/javax/management/relation/RoleUnresolved.java ! src/share/classes/javax/management/relation/RoleUnresolvedList.java ! src/share/classes/javax/management/remote/rmi/NoCallStackClassLoader.java ! src/share/classes/javax/management/remote/rmi/RMIConnection.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java ! src/share/classes/javax/swing/AbstractCellEditor.java ! src/share/classes/javax/swing/AbstractListModel.java ! src/share/classes/javax/swing/AbstractSpinnerModel.java ! src/share/classes/javax/swing/ActionMap.java ! src/share/classes/javax/swing/AncestorNotifier.java ! src/share/classes/javax/swing/ArrayTable.java ! src/share/classes/javax/swing/ButtonGroup.java ! src/share/classes/javax/swing/DefaultBoundedRangeModel.java ! src/share/classes/javax/swing/DefaultButtonModel.java ! src/share/classes/javax/swing/DefaultFocusManager.java ! src/share/classes/javax/swing/DefaultSingleSelectionModel.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/InputMap.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JDialog.java ! src/share/classes/javax/swing/JLayeredPane.java ! src/share/classes/javax/swing/JMenu.java ! src/share/classes/javax/swing/JMenuItem.java ! src/share/classes/javax/swing/JSpinner.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JWindow.java ! src/share/classes/javax/swing/KeyboardManager.java ! src/share/classes/javax/swing/LayoutComparator.java ! src/share/classes/javax/swing/LayoutFocusTraversalPolicy.java ! src/share/classes/javax/swing/LegacyGlueFocusTraversalPolicy.java ! src/share/classes/javax/swing/MultiUIDefaults.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java ! src/share/classes/javax/swing/SpringLayout.java ! src/share/classes/javax/swing/Timer.java ! src/share/classes/javax/swing/TimerQueue.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/UIManager.java ! src/share/classes/javax/swing/border/CompoundBorder.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxEditor.java ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java ! src/share/classes/javax/swing/plaf/basic/BasicGraphicsUtils.java ! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/basic/BasicLabelUI.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicToggleButtonUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java ! src/share/classes/javax/swing/plaf/basic/DragRecognitionSupport.java ! src/share/classes/javax/swing/plaf/basic/LazyActionMap.java ! src/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java ! src/share/classes/javax/swing/plaf/metal/MetalBumps.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/metal/MetalRadioButtonUI.java ! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java ! src/share/classes/javax/swing/plaf/metal/MetalToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/DefaultSynthStyleFactory.java ! src/share/classes/javax/swing/plaf/synth/ImagePainter.java ! src/share/classes/javax/swing/plaf/synth/Region.java ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthContext.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameTitlePane.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/javax/swing/plaf/synth/SynthStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/table/AbstractTableModel.java ! src/share/classes/javax/swing/table/DefaultTableModel.java ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/ComponentView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/ElementIterator.java ! src/share/classes/javax/swing/text/GapContent.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/LayoutQueue.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/SegmentCache.java ! src/share/classes/javax/swing/text/SimpleAttributeSet.java ! src/share/classes/javax/swing/text/StringContent.java ! src/share/classes/javax/swing/text/StyleContext.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/TextAction.java ! src/share/classes/javax/swing/text/TextLayoutStrategy.java ! src/share/classes/javax/swing/text/ZoneView.java ! src/share/classes/javax/swing/text/html/HRuleView.java ! src/share/classes/javax/swing/text/html/HTML.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/HTMLWriter.java ! src/share/classes/javax/swing/text/html/Map.java ! src/share/classes/javax/swing/text/html/MinimalHTMLWriter.java ! src/share/classes/javax/swing/text/html/OptionListModel.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/TableView.java ! src/share/classes/javax/swing/text/html/parser/TagStack.java ! src/share/classes/javax/swing/text/rtf/MockAttributeSet.java ! src/share/classes/javax/swing/text/rtf/RTFParser.java ! src/share/classes/javax/swing/text/rtf/RTFReader.java ! src/share/classes/javax/swing/tree/DefaultTreeCellEditor.java ! src/share/classes/javax/swing/tree/DefaultTreeModel.java ! src/share/classes/javax/swing/tree/FixedHeightLayoutCache.java ! src/share/classes/javax/swing/tree/VariableHeightLayoutCache.java ! src/share/classes/javax/swing/undo/StateEdit.java ! src/share/classes/javax/swing/undo/UndoManager.java ! src/share/classes/javax/swing/undo/UndoableEditSupport.java ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/sun/awt/im/CompositionArea.java ! src/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java ! src/share/classes/sun/net/ProgressEvent.java ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/share/classes/sun/net/httpserver/FixedLengthInputStream.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java ! src/share/classes/sun/swing/AccessibleMethod.java ! src/share/classes/sun/swing/SwingLazyValue.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/classes/sun/swing/plaf/synth/DefaultSynthStyle.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/util/calendar/ZoneInfo.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java ! src/share/native/sun/font/bidi/ubidi.c ! src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! test/java/net/DatagramSocket/SetDatagramSocketImplFactory/ADatagramSocket.sh ! test/java/nio/Buffer/Basic-X.java ! test/java/nio/Buffer/Basic.java ! test/java/nio/Buffer/BasicByte.java ! test/java/nio/Buffer/BasicChar.java ! test/java/nio/Buffer/BasicDouble.java ! test/java/nio/Buffer/BasicFloat.java ! test/java/nio/Buffer/BasicInt.java ! test/java/nio/Buffer/BasicLong.java ! test/java/nio/Buffer/BasicShort.java ! test/java/nio/Buffer/genBasic.sh ! test/java/nio/Buffer/genCopyDirectMemory.sh ! test/java/nio/channels/Channels/Basic.java ! test/java/util/TimeZone/OldIDMappingTest.sh ! test/javax/management/Introspector/AnnotationTest.java ! test/javax/management/MBeanServer/MBeanExceptionTest.java ! test/javax/management/context/ContextTest.java ! test/javax/management/context/LocaleTest.java ! test/javax/management/context/LocalizableTest.java ! test/javax/management/context/localizable/MBeanDescriptions_fr.java ! test/javax/management/context/localizable/Whatsit.java ! test/javax/management/context/localizable/WhatsitMBean.java ! test/javax/management/remote/mandatory/provider/ProviderTest.java ! test/javax/management/remote/mandatory/subjectDelegation/SimpleStandard.java ! test/javax/swing/RepaintManager/6608456/bug6608456.java ! test/javax/swing/text/html/HRuleView/Test5062055.java ! test/javax/xml/crypto/dsig/GenerationTests.java Changeset: 51a20a7ee9c8 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/51a20a7ee9c8 Added tag jdk7-b42 for changeset 3ef0bdfa7609 ! .hgtags Changeset: 4e0e690373fc Author: wetmore Date: 2008-12-02 14:53 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/4e0e690373fc 6778613: Update javax.crypto.Cipher.getMaxAllowedKeyLength to point to proper Appendix after doc reorg Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java Changeset: a99a2d2f3249 Author: dfuchs Date: 2008-12-04 17:58 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/a99a2d2f3249 6319823: new mbean register/unregister notification for groups of mbeans 6779698: Merge error caused duplicate example code in MBeanServerNotification Reviewed-by: emcmanus ! src/share/classes/javax/management/MBeanServerNotification.java Changeset: 87170fc5a587 Author: mchung Date: 2008-12-05 10:28 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/87170fc5a587 6764062: Revise usage of java.io.*.close Summary: Handle closing multiple open I/O streams in case close() throws IOException Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/Installer.java ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/servicetag/Util.java ! src/share/classes/com/sun/servicetag/WindowsSystemEnvironment.java Changeset: baa10242c544 Author: mchung Date: 2008-12-05 10:30 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/baa10242c544 6750389: The cpuManufactorer does not correctly recognized for Solaris 10 Summary: Fix the correct SMBIOS type (4) to obtain CPU manufacturer Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/SolarisSystemEnvironment.java Changeset: ea43ec07a878 Author: tbell Date: 2008-12-05 21:59 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/ea43ec07a878 Merge Changeset: b4bf1806ee66 Author: emcmanus Date: 2008-12-09 12:01 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/b4bf1806ee66 6774918: @NotificationInfo is ineffective on MBeans that cannot send notifications Reviewed-by: jfdenise ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInjector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/NotificationInfo.java ! test/javax/management/Introspector/AnnotatedNotificationInfoTest.java Changeset: 95f828533592 Author: jfdenise Date: 2008-12-09 14:44 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/95f828533592 6501362: DescriptorSupport(String) could recognize "name=value" as well as XML format Reviewed-by: emcmanus ! src/share/classes/javax/management/modelmbean/DescriptorSupport.java + test/javax/management/descriptor/DescriptorConstructorTest.java Changeset: 8d7117d71fc7 Author: jfdenise Date: 2008-12-09 15:36 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/8d7117d71fc7 6250014: MBeanOperationInfo Descriptor field for exceptions Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/mbeanserver/ConvertingMethod.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanIntrospector.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/MBeanOperationInfo.java + test/javax/management/Introspector/ExceptionsDescriptorTest.java Changeset: f8c2f3b5c0ff Author: jfdenise Date: 2008-12-09 15:57 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/f8c2f3b5c0ff 6675526: Define an Annotation to name registered MBeans Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/share/classes/javax/management/Descriptor.java ! src/share/classes/javax/management/JMX.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java + src/share/classes/javax/management/ObjectNameTemplate.java + test/javax/management/Introspector/ObjectNameTemplateTest.java Changeset: ab4d12886aaf Author: jfdenise Date: 2008-12-09 16:14 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/ab4d12886aaf 6450834: RFE: allow StandardMBean to call MBeanRegistration methods on its wrapped resource 6373143: MonitorNotification should have a public constructor Reviewed-by: emcmanus ! src/share/classes/javax/management/StandardMBean.java ! src/share/classes/javax/management/monitor/MonitorNotification.java + test/javax/management/monitor/InstantiateMonitorNotificationTest.java + test/javax/management/standardmbean/RegistrationTest.java Changeset: 3d822c99e3ab Author: jfdenise Date: 2008-12-09 16:26 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3d822c99e3ab 6287328: Add methods to StandardMBean to retrieve a method based on MBean{Attribute|Operation}Info Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/com/sun/jmx/mbeanserver/MBeanIntrospector.java ! src/share/classes/javax/management/StandardMBean.java + test/javax/management/standardmbean/FindMethodTest.java Changeset: 6eec8be80bfe Author: sjiang Date: 2008-12-09 17:41 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/6eec8be80bfe 6405891: MLet: could be improved to load a native lib Reviewed-by: emcmanus ! src/share/classes/javax/management/loading/MLet.java Changeset: 30239cf868b0 Author: sjiang Date: 2008-12-09 17:41 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/30239cf868b0 Merge Changeset: 0b1c7f982cc0 Author: emcmanus Date: 2008-12-09 18:30 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/0b1c7f982cc0 6780803: Wrong parameter name in description of EventClient::addListeners() 6470295: Misleading exception message says context classloader when it isn't 6714954: Description of MBeanPermission checking in MBeanServer javadoc is inaccurate 6732037: Event Service spec needs more detail about Executor use 6740900: Specify that listeners invoked via SendNotification should not block 6778436: Typo in @NotificationInfos spec Reviewed-by: dfuchs ! src/share/classes/com/sun/jmx/mbeanserver/MBeanInstantiator.java ! src/share/classes/javax/management/MBeanRegistration.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/event/EventClient.java ! src/share/classes/javax/management/event/FetchingEventRelay.java Changeset: 23738109351f Author: sjiang Date: 2008-12-09 18:42 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/23738109351f 6760712: Provide a connector server option that causes it not to prevent the VM from exiting Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/rmi/RMIJRMPServerImpl.java + test/javax/management/remote/mandatory/connection/DaemonRMIExporterTest.java Changeset: 0dc9fc01e5d6 Author: sjiang Date: 2008-12-09 18:45 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/0dc9fc01e5d6 Merge Changeset: 4951fee90769 Author: sjiang Date: 2008-12-09 19:44 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/4951fee90769 6332907: Add ability for connector server to close individual connections Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/remote/util/EnvHelp.java ! src/share/classes/javax/management/remote/JMXConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java + test/javax/management/remote/mandatory/connectorServer/CloseConnectionTest.java Changeset: 61e73bc43e72 Author: dfuchs Date: 2008-12-09 20:20 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/61e73bc43e72 6768935: Clarify the behaviour of ObjectName pattern matching with regards to namespaces Reviewed-by: emcmanus ! src/share/classes/com/sun/jmx/interceptor/DispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/DomainDispatchInterceptor.java ! src/share/classes/com/sun/jmx/interceptor/NamespaceDispatchInterceptor.java ! src/share/classes/com/sun/jmx/mbeanserver/MXBeanLookup.java ! src/share/classes/com/sun/jmx/mbeanserver/Util.java ! src/share/classes/com/sun/jmx/namespace/DomainInterceptor.java ! src/share/classes/com/sun/jmx/namespace/NamespaceInterceptor.java ! src/share/classes/com/sun/jmx/namespace/ObjectNameRouter.java ! src/share/classes/com/sun/jmx/namespace/RoutingMBeanServerConnection.java ! src/share/classes/com/sun/jmx/namespace/RoutingProxy.java ! src/share/classes/javax/management/MBeanServer.java ! src/share/classes/javax/management/MBeanServerConnection.java ! src/share/classes/javax/management/ObjectName.java ! src/share/classes/javax/management/namespace/JMXDomain.java ! src/share/classes/javax/management/namespace/JMXNamespacePermission.java ! src/share/classes/javax/management/namespace/JMXNamespaces.java ! src/share/classes/javax/management/namespace/package-info.java ! test/javax/management/namespace/LeadingSeparatorsTest.java ! test/javax/management/namespace/NullDomainObjectNameTest.java ! test/javax/management/namespace/NullObjectNameTest.java ! test/javax/management/namespace/QueryNamesTest.java Changeset: 7aa035fdd97d Author: sjiang Date: 2008-12-09 20:50 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/7aa035fdd97d 6336980: NotificationBroadcasterSupport: to tell whether there are listeners and to do clear Reviewed-by: emcmanus ! src/share/classes/javax/management/NotificationBroadcasterSupport.java + test/javax/management/notification/SupportClearTest.java Changeset: 3f226f477d56 Author: sjiang Date: 2008-12-09 20:51 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/3f226f477d56 Merge Changeset: c8db1ddbdba4 Author: emcmanus Date: 2008-12-10 11:59 +0100 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/c8db1ddbdba4 6456269: Add a GenericMBeanException so clients don't have to have server's exception classes present Reviewed-by: jfdenise, dfuchs ! src/share/classes/javax/management/Descriptor.java + src/share/classes/javax/management/GenericMBeanException.java ! src/share/classes/javax/management/MBeanException.java + test/javax/management/interop/MBeanExceptionInteropTest.java + test/javax/management/openmbean/GenericMBeanExceptionTest.java Changeset: b89ba9a6d9a6 Author: sherman Date: 2008-12-10 14:03 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/b89ba9a6d9a6 6642323: Speeding up Single Byte Decoders 6642328: Speeding up Single Byte Encoders Summary: re-implementation of mapping based sbcs charts Reviewed-by: alanb ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/sun/nio/FILES_java.gmk ! make/sun/nio/Makefile + make/tools/CharsetMapping/IBM037.c2b + make/tools/CharsetMapping/IBM037.map + make/tools/CharsetMapping/IBM037.nr + make/tools/CharsetMapping/IBM1006.map + make/tools/CharsetMapping/IBM1025.c2b + make/tools/CharsetMapping/IBM1025.map + make/tools/CharsetMapping/IBM1025.nr + make/tools/CharsetMapping/IBM1026.c2b + make/tools/CharsetMapping/IBM1026.map + make/tools/CharsetMapping/IBM1026.nr + make/tools/CharsetMapping/IBM1046.map + make/tools/CharsetMapping/IBM1047.map + make/tools/CharsetMapping/IBM1097.map + make/tools/CharsetMapping/IBM1098.map + make/tools/CharsetMapping/IBM1112.c2b + make/tools/CharsetMapping/IBM1112.map + make/tools/CharsetMapping/IBM1112.nr + make/tools/CharsetMapping/IBM1122.c2b + make/tools/CharsetMapping/IBM1122.map + make/tools/CharsetMapping/IBM1122.nr + make/tools/CharsetMapping/IBM1123.c2b + make/tools/CharsetMapping/IBM1123.map + make/tools/CharsetMapping/IBM1123.nr + make/tools/CharsetMapping/IBM1124.map + make/tools/CharsetMapping/IBM1140.c2b + make/tools/CharsetMapping/IBM1140.map + make/tools/CharsetMapping/IBM1141.c2b + make/tools/CharsetMapping/IBM1141.map + make/tools/CharsetMapping/IBM1142.c2b + make/tools/CharsetMapping/IBM1142.map + make/tools/CharsetMapping/IBM1143.c2b + make/tools/CharsetMapping/IBM1143.map + make/tools/CharsetMapping/IBM1144.c2b + make/tools/CharsetMapping/IBM1144.map + make/tools/CharsetMapping/IBM1145.c2b + make/tools/CharsetMapping/IBM1145.map + make/tools/CharsetMapping/IBM1146.c2b + make/tools/CharsetMapping/IBM1146.map + make/tools/CharsetMapping/IBM1147.c2b + make/tools/CharsetMapping/IBM1147.map + make/tools/CharsetMapping/IBM1148.c2b + make/tools/CharsetMapping/IBM1148.map + make/tools/CharsetMapping/IBM1149.c2b + make/tools/CharsetMapping/IBM1149.map + make/tools/CharsetMapping/IBM273.c2b + make/tools/CharsetMapping/IBM273.map + make/tools/CharsetMapping/IBM273.nr + make/tools/CharsetMapping/IBM277.c2b + make/tools/CharsetMapping/IBM277.map + make/tools/CharsetMapping/IBM277.nr + make/tools/CharsetMapping/IBM278.c2b + make/tools/CharsetMapping/IBM278.map + make/tools/CharsetMapping/IBM278.nr + make/tools/CharsetMapping/IBM280.c2b + make/tools/CharsetMapping/IBM280.map + make/tools/CharsetMapping/IBM280.nr + make/tools/CharsetMapping/IBM284.c2b + make/tools/CharsetMapping/IBM284.map + make/tools/CharsetMapping/IBM284.nr + make/tools/CharsetMapping/IBM285.c2b + make/tools/CharsetMapping/IBM285.map + make/tools/CharsetMapping/IBM285.nr + make/tools/CharsetMapping/IBM297.c2b + make/tools/CharsetMapping/IBM297.map + make/tools/CharsetMapping/IBM297.nr + make/tools/CharsetMapping/IBM420.c2b + make/tools/CharsetMapping/IBM420.map + make/tools/CharsetMapping/IBM420.nr + make/tools/CharsetMapping/IBM424.c2b + make/tools/CharsetMapping/IBM424.map + make/tools/CharsetMapping/IBM424.nr + make/tools/CharsetMapping/IBM437.map + make/tools/CharsetMapping/IBM500.c2b + make/tools/CharsetMapping/IBM500.map + make/tools/CharsetMapping/IBM500.nr + make/tools/CharsetMapping/IBM737.map + make/tools/CharsetMapping/IBM775.map + make/tools/CharsetMapping/IBM838.c2b + make/tools/CharsetMapping/IBM838.map + make/tools/CharsetMapping/IBM838.nr + make/tools/CharsetMapping/IBM850.map + make/tools/CharsetMapping/IBM852.map + make/tools/CharsetMapping/IBM855.map + make/tools/CharsetMapping/IBM856.map + make/tools/CharsetMapping/IBM857.map + make/tools/CharsetMapping/IBM858.map + make/tools/CharsetMapping/IBM860.map + make/tools/CharsetMapping/IBM861.map + make/tools/CharsetMapping/IBM862.map + make/tools/CharsetMapping/IBM863.map + make/tools/CharsetMapping/IBM864.map + make/tools/CharsetMapping/IBM865.map + make/tools/CharsetMapping/IBM866.map + make/tools/CharsetMapping/IBM868.map + make/tools/CharsetMapping/IBM869.map + make/tools/CharsetMapping/IBM870.c2b + make/tools/CharsetMapping/IBM870.map + make/tools/CharsetMapping/IBM870.nr + make/tools/CharsetMapping/IBM871.c2b + make/tools/CharsetMapping/IBM871.map + make/tools/CharsetMapping/IBM871.nr + make/tools/CharsetMapping/IBM874.map + make/tools/CharsetMapping/IBM874.nr + make/tools/CharsetMapping/IBM875.c2b + make/tools/CharsetMapping/IBM875.map + make/tools/CharsetMapping/IBM875.nr + make/tools/CharsetMapping/IBM918.c2b + make/tools/CharsetMapping/IBM918.map + make/tools/CharsetMapping/IBM918.nr + make/tools/CharsetMapping/IBM921.map + make/tools/CharsetMapping/IBM922.map + make/tools/CharsetMapping/ISO_8859_11.map + make/tools/CharsetMapping/ISO_8859_13.map + make/tools/CharsetMapping/ISO_8859_15.map + make/tools/CharsetMapping/ISO_8859_2.map + make/tools/CharsetMapping/ISO_8859_3.map + make/tools/CharsetMapping/ISO_8859_4.map + make/tools/CharsetMapping/ISO_8859_5.map + make/tools/CharsetMapping/ISO_8859_6.map + make/tools/CharsetMapping/ISO_8859_7.map + make/tools/CharsetMapping/ISO_8859_8.map + make/tools/CharsetMapping/ISO_8859_9.map + make/tools/CharsetMapping/JIS_X_0201.map + make/tools/CharsetMapping/KOI8_R.map + make/tools/CharsetMapping/KOI8_U.map + make/tools/CharsetMapping/MS1250.map + make/tools/CharsetMapping/MS1251.map + make/tools/CharsetMapping/MS1252.map + make/tools/CharsetMapping/MS1253.map + make/tools/CharsetMapping/MS1254.map + make/tools/CharsetMapping/MS1255.map + make/tools/CharsetMapping/MS1256.map + make/tools/CharsetMapping/MS1257.map + make/tools/CharsetMapping/MS1258.map + make/tools/CharsetMapping/MS874.map + make/tools/CharsetMapping/MacArabic.map + make/tools/CharsetMapping/MacCentralEurope.map + make/tools/CharsetMapping/MacCroatian.map + make/tools/CharsetMapping/MacCyrillic.map + make/tools/CharsetMapping/MacDingbat.map + make/tools/CharsetMapping/MacGreek.map + make/tools/CharsetMapping/MacHebrew.map + make/tools/CharsetMapping/MacIceland.map + make/tools/CharsetMapping/MacRoman.map + make/tools/CharsetMapping/MacRomania.map + make/tools/CharsetMapping/MacSymbol.map + make/tools/CharsetMapping/MacThai.map + make/tools/CharsetMapping/MacTurkish.map + make/tools/CharsetMapping/MacUkraine.map + make/tools/CharsetMapping/SingleByte-X.java + make/tools/CharsetMapping/TIS_620.map + make/tools/CharsetMapping/extsbcs + make/tools/CharsetMapping/sbcs ! make/tools/src/build/tools/charsetmapping/GenerateMapping.java + make/tools/src/build/tools/charsetmapping/GenerateSBCS.java ! src/share/classes/sun/io/ByteToCharCp850.java ! src/share/classes/sun/io/CharToByteJIS0201.java ! src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/nio/cs/IBM437.java - src/share/classes/sun/nio/cs/IBM737.java - src/share/classes/sun/nio/cs/IBM775.java - src/share/classes/sun/nio/cs/IBM850.java - src/share/classes/sun/nio/cs/IBM852.java - src/share/classes/sun/nio/cs/IBM855.java - src/share/classes/sun/nio/cs/IBM857.java - src/share/classes/sun/nio/cs/IBM858.java - src/share/classes/sun/nio/cs/IBM862.java - src/share/classes/sun/nio/cs/IBM866.java - src/share/classes/sun/nio/cs/IBM874.java - src/share/classes/sun/nio/cs/ISO_8859_13.java - src/share/classes/sun/nio/cs/ISO_8859_15.java - src/share/classes/sun/nio/cs/ISO_8859_2.java - src/share/classes/sun/nio/cs/ISO_8859_4.java - src/share/classes/sun/nio/cs/ISO_8859_5.java - src/share/classes/sun/nio/cs/ISO_8859_7.java - src/share/classes/sun/nio/cs/ISO_8859_9.java - src/share/classes/sun/nio/cs/KOI8_R.java - src/share/classes/sun/nio/cs/KOI8_U.java - src/share/classes/sun/nio/cs/MS1250.java - src/share/classes/sun/nio/cs/MS1251.java - src/share/classes/sun/nio/cs/MS1252.java - src/share/classes/sun/nio/cs/MS1253.java - src/share/classes/sun/nio/cs/MS1254.java - src/share/classes/sun/nio/cs/MS1257.java + src/share/classes/sun/nio/cs/SingleByte.java - src/share/classes/sun/nio/cs/ext/IBM037.java - src/share/classes/sun/nio/cs/ext/IBM1006.java - src/share/classes/sun/nio/cs/ext/IBM1025.java - src/share/classes/sun/nio/cs/ext/IBM1026.java - src/share/classes/sun/nio/cs/ext/IBM1046.java - src/share/classes/sun/nio/cs/ext/IBM1047.java - src/share/classes/sun/nio/cs/ext/IBM1097.java - src/share/classes/sun/nio/cs/ext/IBM1098.java - src/share/classes/sun/nio/cs/ext/IBM1112.java - src/share/classes/sun/nio/cs/ext/IBM1122.java - src/share/classes/sun/nio/cs/ext/IBM1123.java - src/share/classes/sun/nio/cs/ext/IBM1124.java - src/share/classes/sun/nio/cs/ext/IBM1140.java - src/share/classes/sun/nio/cs/ext/IBM1141.java - src/share/classes/sun/nio/cs/ext/IBM1142.java - src/share/classes/sun/nio/cs/ext/IBM1143.java - src/share/classes/sun/nio/cs/ext/IBM1144.java - src/share/classes/sun/nio/cs/ext/IBM1145.java - src/share/classes/sun/nio/cs/ext/IBM1146.java - src/share/classes/sun/nio/cs/ext/IBM1147.java - src/share/classes/sun/nio/cs/ext/IBM1148.java - src/share/classes/sun/nio/cs/ext/IBM1149.java - src/share/classes/sun/nio/cs/ext/IBM273.java - src/share/classes/sun/nio/cs/ext/IBM277.java - src/share/classes/sun/nio/cs/ext/IBM278.java - src/share/classes/sun/nio/cs/ext/IBM280.java - src/share/classes/sun/nio/cs/ext/IBM284.java - src/share/classes/sun/nio/cs/ext/IBM285.java - src/share/classes/sun/nio/cs/ext/IBM297.java - src/share/classes/sun/nio/cs/ext/IBM420.java - src/share/classes/sun/nio/cs/ext/IBM424.java - src/share/classes/sun/nio/cs/ext/IBM500.java - src/share/classes/sun/nio/cs/ext/IBM838.java - src/share/classes/sun/nio/cs/ext/IBM856.java - src/share/classes/sun/nio/cs/ext/IBM860.java - src/share/classes/sun/nio/cs/ext/IBM861.java - src/share/classes/sun/nio/cs/ext/IBM863.java - src/share/classes/sun/nio/cs/ext/IBM864.java - src/share/classes/sun/nio/cs/ext/IBM865.java - src/share/classes/sun/nio/cs/ext/IBM868.java - src/share/classes/sun/nio/cs/ext/IBM869.java - src/share/classes/sun/nio/cs/ext/IBM870.java - src/share/classes/sun/nio/cs/ext/IBM871.java - src/share/classes/sun/nio/cs/ext/IBM875.java - src/share/classes/sun/nio/cs/ext/IBM918.java - src/share/classes/sun/nio/cs/ext/IBM921.java - src/share/classes/sun/nio/cs/ext/IBM922.java - src/share/classes/sun/nio/cs/ext/ISO_8859_11.java - src/share/classes/sun/nio/cs/ext/ISO_8859_3.java - src/share/classes/sun/nio/cs/ext/ISO_8859_6.java - src/share/classes/sun/nio/cs/ext/ISO_8859_8.java - src/share/classes/sun/nio/cs/ext/MS1255.java - src/share/classes/sun/nio/cs/ext/MS1256.java - src/share/classes/sun/nio/cs/ext/MS1258.java - src/share/classes/sun/nio/cs/ext/MS874.java - src/share/classes/sun/nio/cs/ext/MacArabic.java - src/share/classes/sun/nio/cs/ext/MacCentralEurope.java - src/share/classes/sun/nio/cs/ext/MacCroatian.java - src/share/classes/sun/nio/cs/ext/MacCyrillic.java - src/share/classes/sun/nio/cs/ext/MacDingbat.java - src/share/classes/sun/nio/cs/ext/MacGreek.java - src/share/classes/sun/nio/cs/ext/MacHebrew.java - src/share/classes/sun/nio/cs/ext/MacIceland.java - src/share/classes/sun/nio/cs/ext/MacRoman.java - src/share/classes/sun/nio/cs/ext/MacRomania.java - src/share/classes/sun/nio/cs/ext/MacSymbol.java - src/share/classes/sun/nio/cs/ext/MacThai.java - src/share/classes/sun/nio/cs/ext/MacTurkish.java - src/share/classes/sun/nio/cs/ext/MacUkraine.java - src/share/classes/sun/nio/cs/ext/TIS_620.java Changeset: 18ab3173fcec Author: tbell Date: 2008-12-19 10:37 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/18ab3173fcec Merge ! src/share/classes/javax/management/MBeanAttributeInfo.java ! src/share/classes/javax/management/MBeanConstructorInfo.java ! src/share/classes/javax/management/remote/rmi/RMIServerImpl.java Changeset: 169685eb3666 Author: glewis at misty.eyesbeyond.com Date: 2008-12-26 16:44 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/169685eb3666 . Merge with the main OpenJDK repositor ! make/common/shared/Sanity.gmk ! make/java/nio/Makefile - src/share/classes/sun/nio/cs/IBM437.java - src/share/classes/sun/nio/cs/IBM737.java - src/share/classes/sun/nio/cs/IBM775.java - src/share/classes/sun/nio/cs/IBM850.java - src/share/classes/sun/nio/cs/IBM852.java - src/share/classes/sun/nio/cs/IBM855.java - src/share/classes/sun/nio/cs/IBM857.java - src/share/classes/sun/nio/cs/IBM858.java - src/share/classes/sun/nio/cs/IBM862.java - src/share/classes/sun/nio/cs/IBM866.java - src/share/classes/sun/nio/cs/IBM874.java - src/share/classes/sun/nio/cs/ISO_8859_13.java - src/share/classes/sun/nio/cs/ISO_8859_15.java - src/share/classes/sun/nio/cs/ISO_8859_2.java - src/share/classes/sun/nio/cs/ISO_8859_4.java - src/share/classes/sun/nio/cs/ISO_8859_5.java - src/share/classes/sun/nio/cs/ISO_8859_7.java - src/share/classes/sun/nio/cs/ISO_8859_9.java - src/share/classes/sun/nio/cs/KOI8_R.java - src/share/classes/sun/nio/cs/KOI8_U.java - src/share/classes/sun/nio/cs/MS1250.java - src/share/classes/sun/nio/cs/MS1251.java - src/share/classes/sun/nio/cs/MS1252.java - src/share/classes/sun/nio/cs/MS1253.java - src/share/classes/sun/nio/cs/MS1254.java - src/share/classes/sun/nio/cs/MS1257.java - src/share/classes/sun/nio/cs/ext/IBM037.java - src/share/classes/sun/nio/cs/ext/IBM1006.java - src/share/classes/sun/nio/cs/ext/IBM1025.java - src/share/classes/sun/nio/cs/ext/IBM1026.java - src/share/classes/sun/nio/cs/ext/IBM1046.java - src/share/classes/sun/nio/cs/ext/IBM1047.java - src/share/classes/sun/nio/cs/ext/IBM1097.java - src/share/classes/sun/nio/cs/ext/IBM1098.java - src/share/classes/sun/nio/cs/ext/IBM1112.java - src/share/classes/sun/nio/cs/ext/IBM1122.java - src/share/classes/sun/nio/cs/ext/IBM1123.java - src/share/classes/sun/nio/cs/ext/IBM1124.java - src/share/classes/sun/nio/cs/ext/IBM1140.java - src/share/classes/sun/nio/cs/ext/IBM1141.java - src/share/classes/sun/nio/cs/ext/IBM1142.java - src/share/classes/sun/nio/cs/ext/IBM1143.java - src/share/classes/sun/nio/cs/ext/IBM1144.java - src/share/classes/sun/nio/cs/ext/IBM1145.java - src/share/classes/sun/nio/cs/ext/IBM1146.java - src/share/classes/sun/nio/cs/ext/IBM1147.java - src/share/classes/sun/nio/cs/ext/IBM1148.java - src/share/classes/sun/nio/cs/ext/IBM1149.java - src/share/classes/sun/nio/cs/ext/IBM273.java - src/share/classes/sun/nio/cs/ext/IBM277.java - src/share/classes/sun/nio/cs/ext/IBM278.java - src/share/classes/sun/nio/cs/ext/IBM280.java - src/share/classes/sun/nio/cs/ext/IBM284.java - src/share/classes/sun/nio/cs/ext/IBM285.java - src/share/classes/sun/nio/cs/ext/IBM297.java - src/share/classes/sun/nio/cs/ext/IBM420.java - src/share/classes/sun/nio/cs/ext/IBM424.java - src/share/classes/sun/nio/cs/ext/IBM500.java - src/share/classes/sun/nio/cs/ext/IBM838.java - src/share/classes/sun/nio/cs/ext/IBM856.java - src/share/classes/sun/nio/cs/ext/IBM860.java - src/share/classes/sun/nio/cs/ext/IBM861.java - src/share/classes/sun/nio/cs/ext/IBM863.java - src/share/classes/sun/nio/cs/ext/IBM864.java - src/share/classes/sun/nio/cs/ext/IBM865.java - src/share/classes/sun/nio/cs/ext/IBM868.java - src/share/classes/sun/nio/cs/ext/IBM869.java - src/share/classes/sun/nio/cs/ext/IBM870.java - src/share/classes/sun/nio/cs/ext/IBM871.java - src/share/classes/sun/nio/cs/ext/IBM875.java - src/share/classes/sun/nio/cs/ext/IBM918.java - src/share/classes/sun/nio/cs/ext/IBM921.java - src/share/classes/sun/nio/cs/ext/IBM922.java - src/share/classes/sun/nio/cs/ext/ISO_8859_11.java - src/share/classes/sun/nio/cs/ext/ISO_8859_3.java - src/share/classes/sun/nio/cs/ext/ISO_8859_6.java - src/share/classes/sun/nio/cs/ext/ISO_8859_8.java - src/share/classes/sun/nio/cs/ext/MS1255.java - src/share/classes/sun/nio/cs/ext/MS1256.java - src/share/classes/sun/nio/cs/ext/MS1258.java - src/share/classes/sun/nio/cs/ext/MS874.java - src/share/classes/sun/nio/cs/ext/MacArabic.java - src/share/classes/sun/nio/cs/ext/MacCentralEurope.java - src/share/classes/sun/nio/cs/ext/MacCroatian.java - src/share/classes/sun/nio/cs/ext/MacCyrillic.java - src/share/classes/sun/nio/cs/ext/MacDingbat.java - src/share/classes/sun/nio/cs/ext/MacGreek.java - src/share/classes/sun/nio/cs/ext/MacHebrew.java - src/share/classes/sun/nio/cs/ext/MacIceland.java - src/share/classes/sun/nio/cs/ext/MacRoman.java - src/share/classes/sun/nio/cs/ext/MacRomania.java - src/share/classes/sun/nio/cs/ext/MacSymbol.java - src/share/classes/sun/nio/cs/ext/MacThai.java - src/share/classes/sun/nio/cs/ext/MacTurkish.java - src/share/classes/sun/nio/cs/ext/MacUkraine.java - src/share/classes/sun/nio/cs/ext/TIS_620.java Changeset: 0ff335e5267c Author: glewis at misty.eyesbeyond.com Date: 2008-12-26 17:23 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/0ff335e5267c . Merge with the main BSD repo. From ekrichardson at gmail.com Sat Dec 27 23:12:33 2008 From: ekrichardson at gmail.com (Eric Richardson) Date: Sat, 27 Dec 2008 23:12:33 -0800 Subject: Power PC Build Message-ID: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> Hi, I was looking into OpenJDK and saw the bsd-port and zero assembly project and thought It might be possible build jdk6 on PowerPC. After looking at the bsd-port list I started working on setting up my environment. I have a G5 based Mac. Here is what I have done so far. Installed MacOSX 10.5 Installed XCode 3.1.2 Installed Fink 0.9.0 Installed Mercurial Checked out icetea6 (hg clone http://...) ./autogen.sh ./configure gawk not found apt-get install gawk checking for a GCJ JDK home directory... configure: error: "A GCJ JDK home directory could not be found." ./configure --with-gcj-home=/Library/Java/Home --enable-zero=yes checking for eclipse-ecj.jar... no configure: error: "A ECJ jar was not found." Next error waiting if I fix the above. checking xalan2 jar... no configure: error: "A xalan2 jar was not found." Before I go further, I thought I'd ask if this is going to work at all using the JDK 5 that comes with MacOSX? Any suggestions on how to proceed? Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081227/48f3c764/attachment.html From glewis at eyesbeyond.com Sun Dec 28 00:29:26 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Sun, 28 Dec 2008 00:29:26 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <20081226172736.GA42840@misty.eyesbeyond.com> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> <494FE536.1040102@Sun.COM> <20081226072429.GA69479@misty.eyesbeyond.com> <49548922.80703@Sun.COM> <20081226172736.GA42840@misty.eyesbeyond.com> Message-ID: <20081228082926.GA77650@misty.eyesbeyond.com> On Fri, Dec 26, 2008 at 09:27:36AM -0800, Greg Lewis wrote: > On Thu, Dec 25, 2008 at 11:34:58PM -0800, Xiaobin Lu wrote: > > So with my openjdk id, I can commit the changes without extra permission? > > I think I should have looked harder at the change first, sorry. I tried > compiling with that change in and it broke the i386 build :(. I'm looking > at things side by side with the current Linux code to try and get the > braces and #ifdef's right, but I have to say this part of the code is > becoming quite confusing with the proliferation of preprocessor > conditionals. > > I hope to have something later today that you can test on Mac OS X. Instead I shovelled snow/ice for a couple of days so we could get out of our house to the main roads :). Anyway, attached is a patch. Its not yet compile tested, I've got the compile started however and will check in the morning. Please give it a try on Mac OS X. Basically it looks like the special handling for 64 bit Mac OS X was half merged into the x86 handling. > > Greg Lewis wrote: > > > G'day Xiaobin, > > > > > > On Mon, Dec 22, 2008 at 11:06:30AM -0800, Xiaobin Lu wrote: > > > > > >> I am attaching the patch to make the VM build pass on Mac OS 64 bit. > > >> Here is some explanation on the change: > > >> > > >> bytes_bsd_x86.inline.cpp: > > >> > > >> Change bswap16(x) to bswap_16(x) and the similar, I believe there was a > > >> typo for this. When some ported this to Apple platform, they missed a > > >> underscore. > > >> > > >> os_bsd_x86.cpp > > >> > > >> There was a "}" missing for 64 bit build. > > >> > > > > > > Thats a lot clearer when I use diff -b :). > > > > > > > > >> Other changes to make the build pass will be covered by my fix to > > >> 6787106 which I am going to put back to open JDK 7 tree soon. > > >> > > >> Please help me review the patch and feel free to let me know if there > > >> was anything wrong. > > >> > > > > > > Looks good to me -- I say go ahead and commit it. > > > > > > > > >> Greg Lewis wrote: > > >> > > >>> G'day Xiaobin, > > >>> > > >>> On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: > > >>> > > >>> > > >>>> I am attaching the patch for building 64 bit VM. They are BSD specific > > >>>> files. Would someone review it and help me check it in? > > >>>> > > >>>> > > >>> Sure. Can you comment a little on the changes to > > >>> src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is > > >>> bigger than the changes if that makes sense (i.e. there are some whitespace > > >>> changes due to control flow changes which are hiding those). > > >>> > > >>> > > >>> > > > > > > > > > > > > > > -- > Greg Lewis Email : glewis at eyesbeyond.com > Eyes Beyond Web : http://www.eyesbeyond.com > Information Technology FreeBSD : glewis at FreeBSD.org -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From glewis at eyesbeyond.com Sun Dec 28 00:30:36 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Sun, 28 Dec 2008 00:30:36 -0800 Subject: hg: bsd-port/bsd-port/jdk: 41 new changesets In-Reply-To: <20081227013322.A5A78DF95@hg.openjdk.java.net> References: <20081227013322.A5A78DF95@hg.openjdk.java.net> Message-ID: <20081228083036.GB77650@misty.eyesbeyond.com> On Sat, Dec 27, 2008 at 01:25:30AM +0000, glewis at eyesbeyond.com wrote: > . Merge with the main OpenJDK repository This is all the merging done except for HotSpot. That will require a bit more work which I haven't had a chance to do yet. -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From mvfranz at gmail.com Sun Dec 28 08:52:26 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 28 Dec 2008 11:52:26 -0500 Subject: Power PC Build In-Reply-To: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> Message-ID: Eric, I have looked at compiling IcedTea for OS X prior to the BSD port being public. I was not successful. I use Macports and had some of the necessary dependencies added to it (eclipse-ecj). I also only have Intel macs so I can use the OpenJDK BSD port to bootstrap. I don't have my notes handy, but I was using Java 6 (at the time Apple's Java 6 was not complete) and had some issues with compling some classes. I tried to get Red Hat's modified gcc/gcj but it would not compile. GCC 4.3 was not released yet, but I think it is now. Gcc 4.3 should work as an alternative - no guarentees. Will Java 5 work? I don't know. I was recently looking at using the zero port in Icedtea, but never completed the build process either. I can post my configure script when I have access if you are still interested. Michael On Sun, Dec 28, 2008 at 2:12 AM, Eric Richardson wrote: > Hi, > > I was looking into OpenJDK and saw the bsd-port and zero assembly project > and thought It might be possible build jdk6 on PowerPC. After looking at > the bsd-port list I started working on setting up my environment. I have a > G5 based Mac. Here is what I have done so far. > > Installed MacOSX 10.5 > Installed XCode 3.1.2 > Installed Fink 0.9.0 > Installed Mercurial > Checked out icetea6 (hg clone http://...) > ./autogen.sh > ./configure > > gawk not found > apt-get install gawk > > checking for a GCJ JDK home directory... > configure: error: "A GCJ JDK home directory could not be found." > > ./configure --with-gcj-home=/Library/Java/Home --enable-zero=yes > > checking for eclipse-ecj.jar... no > configure: error: "A ECJ jar was not found." > > Next error waiting if I fix the above. > checking xalan2 jar... no > configure: error: "A xalan2 jar was not found." > > Before I go further, I thought I'd ask if this is going to work at all > using the JDK 5 that comes with MacOSX? > Any suggestions on how to proceed? > > Thanks, > Eric > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081228/9bbefbe0/attachment.html From glewis at eyesbeyond.com Sun Dec 28 10:29:36 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Sun, 28 Dec 2008 10:29:36 -0800 Subject: Power PC Build In-Reply-To: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> Message-ID: <20081228182936.GA7488@misty.eyesbeyond.com> G'day Eric, On Sat, Dec 27, 2008 at 11:12:33PM -0800, Eric Richardson wrote: > I was looking into OpenJDK and saw the bsd-port and zero assembly project > and thought It might be possible build jdk6 on PowerPC. After looking at > the bsd-port list I started working on setting up my environment. I have a > G5 based Mac. Here is what I have done so far. Depending on what you want in terms of a JDK, it might be easier to try and port the zero assembler work to the current OpenJDK BSD port. I'd like to do this, but I've not seen zero assembler separated out from the Iced Tea sources. I believe you need libffi working to get it to work, but there are ports for this in MacPorts and in at least the FreeBSD ports system (I expect it to be in {Net,Open}BSD as well). CC'ing Gary Benson, the zero assembler author. Gary, would it be possible to get the zero assembler support as a patch against the current OpenJDK 7 sources or could you point out the relevant parts of the Iced Tea source? The other option for getting OpenJDK on Mac OS X / PowerPC is to port the BSD support to Iced Tea. Thats certainly doable, but I imagine its a bigger job. > Installed MacOSX 10.5 > Installed XCode 3.1.2 > Installed Fink 0.9.0 > Installed Mercurial > Checked out icetea6 (hg clone http://...) > ./autogen.sh > ./configure > > gawk not found > apt-get install gawk > > checking for a GCJ JDK home directory... > configure: error: "A GCJ JDK home directory could not be found." > > ./configure --with-gcj-home=/Library/Java/Home --enable-zero=yes > > checking for eclipse-ecj.jar... no > configure: error: "A ECJ jar was not found." > > Next error waiting if I fix the above. > checking xalan2 jar... no > configure: error: "A xalan2 jar was not found." > > Before I go further, I thought I'd ask if this is going to work at all using > the JDK 5 that comes with MacOSX? > Any suggestions on how to proceed? > > Thanks, > Eric > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From glewis at eyesbeyond.com Sun Dec 28 10:35:44 2008 From: glewis at eyesbeyond.com (glewis at eyesbeyond.com) Date: Sun, 28 Dec 2008 18:35:44 +0000 Subject: hg: bsd-port/bsd-port/jdk: . Implement the -XstartOnFirstThread flag on Mac OS X. This is required Message-ID: <20081228183555.CC9B8DFAB@hg.openjdk.java.net> Changeset: 2a26505c1304 Author: glewis at misty.eyesbeyond.com Date: 2008-12-28 10:34 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/jdk/rev/2a26505c1304 . Implement the -XstartOnFirstThread flag on Mac OS X. This is required for Eclipse to work there. Submitted by: Michael Franz ! src/share/bin/java.c From mvfranz at gmail.com Sun Dec 28 11:06:38 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 28 Dec 2008 14:06:38 -0500 Subject: Power PC Build In-Reply-To: <20081228182936.GA7488@misty.eyesbeyond.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> Message-ID: On Sun, Dec 28, 2008 at 1:29 PM, Greg Lewis wrote: > G'day Eric, > > On Sat, Dec 27, 2008 at 11:12:33PM -0800, Eric Richardson wrote: > > I was looking into OpenJDK and saw the bsd-port and zero assembly project > > and thought It might be possible build jdk6 on PowerPC. After looking at > > the bsd-port list I started working on setting up my environment. I have > a > > G5 based Mac. Here is what I have done so far. > > Depending on what you want in terms of a JDK, it might be easier to try > and port the zero assembler work to the current OpenJDK BSD port. I'd > like to do this, but I've not seen zero assembler separated out from the > Iced Tea sources. I believe you need libffi working to get it to work, > but there are ports for this in MacPorts and in at least the FreeBSD > ports system (I expect it to be in {Net,Open}BSD as well). > > CC'ing Gary Benson, the zero assembler author. Gary, would it be > possible to get the zero assembler support as a patch against the > current OpenJDK 7 sources or could you point out the relevant parts > of the Iced Tea source? > There is a zero forest here http://hg.openjdk.java.net/ . Is this the official source? Or is it mostly maintained within the IcedTea project? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081228/26ae0239/attachment.html From glewis at eyesbeyond.com Sun Dec 28 12:55:41 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Sun, 28 Dec 2008 12:55:41 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <20081228082926.GA77650@misty.eyesbeyond.com> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> <494FE536.1040102@Sun.COM> <20081226072429.GA69479@misty.eyesbeyond.com> <49548922.80703@Sun.COM> <20081226172736.GA42840@misty.eyesbeyond.com> <20081228082926.GA77650@misty.eyesbeyond.com> Message-ID: <20081228205541.GA11757@misty.eyesbeyond.com> On Sun, Dec 28, 2008 at 12:29:26AM -0800, Greg Lewis wrote: > On Fri, Dec 26, 2008 at 09:27:36AM -0800, Greg Lewis wrote: > > On Thu, Dec 25, 2008 at 11:34:58PM -0800, Xiaobin Lu wrote: > > > So with my openjdk id, I can commit the changes without extra permission? > > > > I think I should have looked harder at the change first, sorry. I tried > > compiling with that change in and it broke the i386 build :(. I'm looking > > at things side by side with the current Linux code to try and get the > > braces and #ifdef's right, but I have to say this part of the code is > > becoming quite confusing with the proliferation of preprocessor > > conditionals. > > > > I hope to have something later today that you can test on Mac OS X. > > Instead I shovelled snow/ice for a couple of days so we could get out of > our house to the main roads :). > > Anyway, attached is a patch. Its not yet compile tested, I've got the > compile started however and will check in the morning. Please give it > a try on Mac OS X. Basically it looks like the special handling for > 64 bit Mac OS X was half merged into the x86 handling. Oops, as Kurt pointed out I forgot to attach the patch... Trying again. > > > Greg Lewis wrote: > > > > G'day Xiaobin, > > > > > > > > On Mon, Dec 22, 2008 at 11:06:30AM -0800, Xiaobin Lu wrote: > > > > > > > >> I am attaching the patch to make the VM build pass on Mac OS 64 bit. > > > >> Here is some explanation on the change: > > > >> > > > >> bytes_bsd_x86.inline.cpp: > > > >> > > > >> Change bswap16(x) to bswap_16(x) and the similar, I believe there was a > > > >> typo for this. When some ported this to Apple platform, they missed a > > > >> underscore. > > > >> > > > >> os_bsd_x86.cpp > > > >> > > > >> There was a "}" missing for 64 bit build. > > > >> > > > > > > > > Thats a lot clearer when I use diff -b :). > > > > > > > > > > > >> Other changes to make the build pass will be covered by my fix to > > > >> 6787106 which I am going to put back to open JDK 7 tree soon. > > > >> > > > >> Please help me review the patch and feel free to let me know if there > > > >> was anything wrong. > > > >> > > > > > > > > Looks good to me -- I say go ahead and commit it. > > > > > > > > > > > >> Greg Lewis wrote: > > > >> > > > >>> G'day Xiaobin, > > > >>> > > > >>> On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: > > > >>> > > > >>> > > > >>>> I am attaching the patch for building 64 bit VM. They are BSD specific > > > >>>> files. Would someone review it and help me check it in? > > > >>>> > > > >>>> > > > >>> Sure. Can you comment a little on the changes to > > > >>> src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is > > > >>> bigger than the changes if that makes sense (i.e. there are some whitespace > > > >>> changes due to control flow changes which are hiding those). > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > > > -- > > Greg Lewis Email : glewis at eyesbeyond.com > > Eyes Beyond Web : http://www.eyesbeyond.com > > Information Technology FreeBSD : glewis at FreeBSD.org > > -- > Greg Lewis Email : glewis at eyesbeyond.com > Eyes Beyond Web : http://www.eyesbeyond.com > Information Technology FreeBSD : glewis at FreeBSD.org -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org -------------- next part -------------- A non-text attachment was scrubbed... Name: os_bsd_x86.cpp.diff Type: text/x-diff Size: 1819 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081228/6bc86815/attachment.bin From Xiaobin.Lu at Sun.COM Sun Dec 28 13:35:49 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Sun, 28 Dec 2008 13:35:49 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <20081228205541.GA11757@misty.eyesbeyond.com> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> <494FE536.1040102@Sun.COM> <20081226072429.GA69479@misty.eyesbeyond.com> <49548922.80703@Sun.COM> <20081226172736.GA42840@misty.eyesbeyond.com> <20081228082926.GA77650@misty.eyesbeyond.com> <20081228205541.GA11757@misty.eyesbeyond.com> Message-ID: <4957F135.3040300@Sun.COM> I tested your patch and it worked fine on 32 & 64 bit build. However, we still need the patch for src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp. The patch looks like the following: diff -r de4c58dbee8f src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp --- a/src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp Wed Nov 26 05:05:13 2008 -0800 +++ b/src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp Wed Dec 17 21:06:49 2008 -0800 @@ -32,9 +32,9 @@ #if defined(AMD64) # if defined(__APPLE__) -# define bswap16(x) OSSwapInt16(x) -# define bswap32(x) OSSwapInt32(x) -# define bswap64(x) OSSwapInt64(x) +# define bswap_16(x) OSSwapInt16(x) +# define bswap_32(x) OSSwapInt32(x) +# define bswap_64(x) OSSwapInt64(x) # elif defined(__OpenBSD__) # define bswap_16(x) swap16(x) # define bswap_32(x) swap32(x) You may want to check in the above as well. By the way, I've already integrated my fix to solve the intptr_t and int32_t into hotspot-rt repository (http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot). It will probably take another week for the fix to show up in the hotspot main repository. Regards, -Xiaobin Greg Lewis wrote: > On Sun, Dec 28, 2008 at 12:29:26AM -0800, Greg Lewis wrote: > >> On Fri, Dec 26, 2008 at 09:27:36AM -0800, Greg Lewis wrote: >> >>> On Thu, Dec 25, 2008 at 11:34:58PM -0800, Xiaobin Lu wrote: >>> >>>> So with my openjdk id, I can commit the changes without extra permission? >>>> >>> I think I should have looked harder at the change first, sorry. I tried >>> compiling with that change in and it broke the i386 build :(. I'm looking >>> at things side by side with the current Linux code to try and get the >>> braces and #ifdef's right, but I have to say this part of the code is >>> becoming quite confusing with the proliferation of preprocessor >>> conditionals. >>> >>> I hope to have something later today that you can test on Mac OS X. >>> >> Instead I shovelled snow/ice for a couple of days so we could get out of >> our house to the main roads :). >> >> Anyway, attached is a patch. Its not yet compile tested, I've got the >> compile started however and will check in the morning. Please give it >> a try on Mac OS X. Basically it looks like the special handling for >> 64 bit Mac OS X was half merged into the x86 handling. >> > > Oops, as Kurt pointed out I forgot to attach the patch... Trying again. > > >>>> Greg Lewis wrote: >>>> >>>>> G'day Xiaobin, >>>>> >>>>> On Mon, Dec 22, 2008 at 11:06:30AM -0800, Xiaobin Lu wrote: >>>>> >>>>> >>>>>> I am attaching the patch to make the VM build pass on Mac OS 64 bit. >>>>>> Here is some explanation on the change: >>>>>> >>>>>> bytes_bsd_x86.inline.cpp: >>>>>> >>>>>> Change bswap16(x) to bswap_16(x) and the similar, I believe there was a >>>>>> typo for this. When some ported this to Apple platform, they missed a >>>>>> underscore. >>>>>> >>>>>> os_bsd_x86.cpp >>>>>> >>>>>> There was a "}" missing for 64 bit build. >>>>>> >>>>>> >>>>> Thats a lot clearer when I use diff -b :). >>>>> >>>>> >>>>> >>>>>> Other changes to make the build pass will be covered by my fix to >>>>>> 6787106 which I am going to put back to open JDK 7 tree soon. >>>>>> >>>>>> Please help me review the patch and feel free to let me know if there >>>>>> was anything wrong. >>>>>> >>>>>> >>>>> Looks good to me -- I say go ahead and commit it. >>>>> >>>>> >>>>> >>>>>> Greg Lewis wrote: >>>>>> >>>>>> >>>>>>> G'day Xiaobin, >>>>>>> >>>>>>> On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I am attaching the patch for building 64 bit VM. They are BSD specific >>>>>>>> files. Would someone review it and help me check it in? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Sure. Can you comment a little on the changes to >>>>>>> src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is >>>>>>> bigger than the changes if that makes sense (i.e. there are some whitespace >>>>>>> changes due to control flow changes which are hiding those). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>> -- >>> Greg Lewis Email : glewis at eyesbeyond.com >>> Eyes Beyond Web : http://www.eyesbeyond.com >>> Information Technology FreeBSD : glewis at FreeBSD.org >>> >> -- >> Greg Lewis Email : glewis at eyesbeyond.com >> Eyes Beyond Web : http://www.eyesbeyond.com >> Information Technology FreeBSD : glewis at FreeBSD.org >> > > From gnu_andrew at member.fsf.org Sun Dec 28 15:26:49 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Sun, 28 Dec 2008 23:26:49 +0000 Subject: Power PC Build In-Reply-To: <20081228182936.GA7488@misty.eyesbeyond.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> Message-ID: <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> [ccing IcedTea list too] 2008/12/28 Greg Lewis : > G'day Eric, > > On Sat, Dec 27, 2008 at 11:12:33PM -0800, Eric Richardson wrote: >> I was looking into OpenJDK and saw the bsd-port and zero assembly project >> and thought It might be possible build jdk6 on PowerPC. After looking at >> the bsd-port list I started working on setting up my environment. I have a >> G5 based Mac. Here is what I have done so far. > Note that the proprietary JDK6 isn't supported as a JDK for building IcedTea. IcedTea was originally created so that OpenJDK could be built without proprietary build tools or plugs. Both are still needed with the JDK7 tree. It's possible to build 6 without plugs now, but I guess you can't build it without an existing copy of IcedTea. Of course, if there is some fix that makes the Mac OS JDK work for you in building IcedTea, then we are open to patches. But supporting proprietary JDKs as build tools is not a primary goal of the project (i.e. no-one's going to be testing it still works on a daily basis). Your best option would be to try --with-openjdk as a build option. I know IcedTea7 won't work with a Sun JDK being used as the GCJ JDK at present, as there are some fixes specific to header files and differences between gjavah and javah from the JDK. > Depending on what you want in terms of a JDK, it might be easier to try > and port the zero assembler work to the current OpenJDK BSD port. I'd > like to do this, but I've not seen zero assembler separated out from the > Iced Tea sources. I believe you need libffi working to get it to work, > but there are ports for this in MacPorts and in at least the FreeBSD > ports system (I expect it to be in {Net,Open}BSD as well). > You do libffi for IcedTea's zero support. Should you want to also try Shark (the zero-assembler JIT support) sometime in the future, you also need LLVM but this is still a work-in-progress, especially on 64-bit archs. > CC'ing Gary Benson, the zero assembler author. Gary, would it be > possible to get the zero assembler support as a patch against the > current OpenJDK 7 sources or could you point out the relevant parts > of the Iced Tea source? > I guess you'll probably get a response from this from Gary tomorrow, but my feeling would be that, while it would be possible to provide zero separately, it's not going to be something that's possible to support long term as Gary does his work primarily on GNU/Linux within IcedTea. The relevant bits are the ports subdirectory and a number of patches from the patches subdirectory. You need to comb the Makefile.am a bit to find these. > The other option for getting OpenJDK on Mac OS X / PowerPC is to port > the BSD support to Iced Tea. Thats certainly doable, but I imagine its > a bigger job. > IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a --with-project=bsd option for supporting using the BSD tree in place of the main JDK7 tree. It just needs testing. I think supporting the use of BSD as an alternate icedTea build is the better solution long term. All it really needs is someone will to try building on Mac OS/BSD and to maintain it long-term by supplying us with patches. No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK) but we're certainly open to more contributors and to supporting more platforms. I'd much prefer this to forking zero support. There are also other features such as the web plugin, web start support, etc. in IcedTea that may be useful for BSD and Mac OS X users. >> Installed MacOSX 10.5 >> Installed XCode 3.1.2 >> Installed Fink 0.9.0 >> Installed Mercurial >> Checked out icetea6 (hg clone http://...) >> ./autogen.sh >> ./configure >> >> gawk not found >> apt-get install gawk >> >> checking for a GCJ JDK home directory... >> configure: error: "A GCJ JDK home directory could not be found." >> >> ./configure --with-gcj-home=/Library/Java/Home --enable-zero=yes >> >> checking for eclipse-ecj.jar... no >> configure: error: "A ECJ jar was not found." >> >> Next error waiting if I fix the above. >> checking xalan2 jar... no >> configure: error: "A xalan2 jar was not found." >> >> Before I go further, I thought I'd ask if this is going to work at all using >> the JDK 5 that comes with MacOSX? >> Any suggestions on how to proceed? >> >> Thanks, >> Eric > >> > > > -- > Greg Lewis Email : glewis at eyesbeyond.com > Eyes Beyond Web : http://www.eyesbeyond.com > Information Technology FreeBSD : glewis at FreeBSD.org > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ekrichardson at gmail.com Sun Dec 28 16:54:48 2008 From: ekrichardson at gmail.com (Eric Richardson) Date: Sun, 28 Dec 2008 16:54:48 -0800 Subject: Power PC Build In-Reply-To: References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> Message-ID: <860cb0120812281654t54005e1el2cfa2b243c155f82@mail.gmail.com> Hi Michael, On Sun, Dec 28, 2008 at 8:52 AM, Michael Franz wrote: > Eric, > > I have looked at compiling IcedTea for OS X prior to the BSD port being > public. I was not successful. I use Macports and had some of the necessary > dependencies added to it (eclipse-ecj). I also only have Intel macs so I > can use the OpenJDK BSD port to bootstrap. Thanks for this MacPorts tip as this helped me past my eclipse-ecj hurdle. > > I don't have my notes handy, but I was using Java 6 (at the time Apple's > Java 6 was not complete) and had some issues with compling some classes. I > tried to get Red Hat's modified gcc/gcj but it would not compile. GCC 4.3 > was not released yet, but I think it is now. Gcc 4.3 should work as an > alternative - no guarentees. Will Java 5 work? I don't know. > > I was recently looking at using the zero port in Icedtea, but never > completed the build process either. I read some more on the IceTea site and it looks like this should be possible. > > I can post my configure script when I have access if you are still > interested. > > Michael Eric > > > On Sun, Dec 28, 2008 at 2:12 AM, Eric Richardson wrote: > >> Hi, >> >> I was looking into OpenJDK and saw the bsd-port and zero assembly project >> and thought It might be possible build jdk6 on PowerPC. After looking at >> the bsd-port list I started working on setting up my environment. I have a >> G5 based Mac. Here is what I have done so far. >> >> Installed MacOSX 10.5 >> Installed XCode 3.1.2 >> Installed Fink 0.9.0 >> Installed Mercurial >> Checked out icetea6 (hg clone http://...) >> ./autogen.sh >> ./configure >> >> gawk not found >> apt-get install gawk >> >> checking for a GCJ JDK home directory... >> configure: error: "A GCJ JDK home directory could not be found." >> >> ./configure --with-gcj-home=/Library/Java/Home --enable-zero=yes >> >> checking for eclipse-ecj.jar... no >> configure: error: "A ECJ jar was not found." >> >> Next error waiting if I fix the above. >> checking xalan2 jar... no >> configure: error: "A xalan2 jar was not found." >> >> Before I go further, I thought I'd ask if this is going to work at all >> using the JDK 5 that comes with MacOSX? >> Any suggestions on how to proceed? >> >> Thanks, >> Eric >> >> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081228/1d5cea8e/attachment.html From glewis at eyesbeyond.com Sun Dec 28 18:20:30 2008 From: glewis at eyesbeyond.com (glewis at eyesbeyond.com) Date: Mon, 29 Dec 2008 02:20:30 +0000 Subject: hg: bsd-port/bsd-port/hotspot: 59 new changesets Message-ID: <20081229022222.95DB6DFB0@hg.openjdk.java.net> Changeset: 2e4f74ff86a1 Author: xdono Date: 2008-12-04 11:10 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/2e4f74ff86a1 Added tag jdk7-b41 for changeset f9d938ede196 ! .hgtags Changeset: 2b42b31e7928 Author: coleenp Date: 2008-11-21 08:09 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/2b42b31e7928 6676175: BigApps crash JVM Client VM (build 10.0-b22, mixed mode, sharing) with SIGSEGV (0xb) Summary: Add test for biased locking epoch before walking own thread stack in case of rare race Reviewed-by: phh, never ! src/share/vm/runtime/biasedLocking.cpp Changeset: ba7f9d894282 Author: kamg Date: 2008-11-21 15:10 -0500 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/ba7f9d894282 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp Changeset: 171e581e8161 Author: xlu Date: 2008-11-22 00:16 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/171e581e8161 6554406: Change switch UseVMInterruptibleIO default to false (sol) Summary: The default value of UseVMInterruptibleIO is changed to false for JDK 7, but the default isn't changed for JDK 6 and earlier. Reviewed-by: never, acorn, dholmes, kamg, alanb ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: b22701a8b88f Author: coleenp Date: 2008-11-24 14:45 -0500 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b22701a8b88f 6474243: suspicious jvmti code that uses oop unsafely across GC point Summary: oop stored in unsafely in Lscratch noticed by visual inspection will not be updated by GC. Reviewed-by: kamg, never, kvn ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: a60eabc24e2c Author: kamg Date: 2008-11-25 15:59 -0500 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/a60eabc24e2c Merge Changeset: 00b023ae2d78 Author: ysr Date: 2008-11-20 12:27 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/00b023ae2d78 6722113: CMS: Incorrect overflow handling during precleaning of Reference lists Summary: When we encounter marking stack overflow during precleaning of Reference lists, we were using the overflow list mechanism, which can cause problems on account of mutating the mark word of the header because of conflicts with mutator accesses and updates of that field. Instead we should use the usual mechanism for overflow handling in concurrent phases, namely dirtying of the card on which the overflowed object lies. Since precleaning effectively does a form of discovered list processing, albeit with discovery enabled, we needed to adjust some code to be correct in the face of interleaved processing and discovery. Reviewed-by: apetrusenko, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/globals.hpp Changeset: c96030fff130 Author: ysr Date: 2008-11-20 16:56 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/c96030fff130 6684579: SoftReference processing can be made more efficient Summary: For current soft-ref clearing policies, we can decide at marking time if a soft-reference will definitely not be cleared, postponing the decision of whether it will definitely be cleared to the final reference processing phase. This can be especially beneficial in the case of concurrent collectors where the marking is usually concurrent but reference processing is usually not. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/utilities/macros.hpp Changeset: df4305d4c1a1 Author: ysr Date: 2008-11-24 09:53 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/df4305d4c1a1 6774607: SIGSEGV or (!is_null(v),"oop value can never be zero") assertion when running with CMS and COOPs Summary: Use the more permissive set_klass_or_null() and klass_or_null() interfaces in ParNew's workqueue overflow code that manipulates the klass-word. Reviewed-by: coleenp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/oops/oop.inline.hpp Changeset: 434912c745cf Author: iveresov Date: 2008-11-26 09:24 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/434912c745cf Merge ! src/share/vm/runtime/globals.hpp Changeset: b6272ef4a18f Author: poonam Date: 2008-11-27 18:19 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b6272ef4a18f 6743339: Enable building sa-jdi.jar and sawindbg.dll on Windows with hotspot build Summary: These changes enable the SA binaries build with hotspot build on Windows Reviewed-by: swamyv ! make/windows/build.make ! make/windows/makefiles/defs.make ! make/windows/makefiles/sa.make Changeset: 27a80744a83b Author: ysr Date: 2008-12-01 23:25 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/27a80744a83b 6778647: snap(), snap_policy() should be renamed setup(), setup_policy() Summary: Renamed Reference{Policy,Pocessor} methods from snap{,_policy}() to setup{,_policy}() Reviewed-by: apetrusenko ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp Changeset: 95cad1ab2510 Author: jmasa Date: 2008-12-03 14:44 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/95cad1ab2510 Merge Changeset: 3a86a8dcf27c Author: never Date: 2008-11-25 13:14 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/3a86a8dcf27c 6756768: C1 generates invalid code Reviewed-by: kvn, jrose ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_ValueMap.hpp + test/compiler/6756768/Test6756768.java + test/compiler/6756768/Test6756768_2.java Changeset: 424f9bfe6b96 Author: kvn Date: 2008-12-03 13:41 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/424f9bfe6b96 6775880: EA +DeoptimizeALot: assert(mon_info->owner()->is_locked(),"object must be locked now") Summary: Create new "eliminated" BoxLock node for monitor debug info when corresponding locks are eliminated. Reviewed-by: never ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/output.cpp + test/compiler/6775880/Test.java Changeset: 1f54ed41d6ae Author: kvn Date: 2008-12-04 08:55 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/1f54ed41d6ae Merge Changeset: 85f1b9537f70 Author: iveresov Date: 2008-12-03 14:18 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/85f1b9537f70 6779436: NUMA allocator: libnuma expects certain size of the buffer in numa_node_to_cpus() Summary: In os::Linux::rebuild_cpu_to_node_map() fix the size of the CPU bitmap. Fixed arithmetic in MutableNUMASpace::adaptive_chunk_size() that could cause overflows and underflows of the chunk_size variable. Reviewed-by: apetrusenko ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/runtime/globals.hpp Changeset: ab25f609be4a Author: jmasa Date: 2008-12-04 09:04 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/ab25f609be4a Merge Changeset: 8a0c882e46d6 Author: jmasa Date: 2008-12-04 13:21 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/8a0c882e46d6 Merge Changeset: dc16daa0329d Author: poonam Date: 2008-12-04 17:29 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/dc16daa0329d 6739363: Xcheck jni doesn't check native function arguments Summary: Fix adds support for verifying arguments with -Xcheck:jni. Reviewed-by: coleenp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 63d1bf926938 Author: poonam Date: 2008-12-04 17:48 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/63d1bf926938 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/concurrentGCThread.hpp Changeset: 8724fb00c422 Author: blacklion Date: 2008-12-05 15:06 -0500 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/8724fb00c422 Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/includeDB_core Changeset: 7cee1a61ffd7 Author: trims Date: 2008-12-05 15:32 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/7cee1a61ffd7 Merge Changeset: 3c4d36b4a7ac Author: trims Date: 2008-12-05 15:45 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/3c4d36b4a7ac 6781742: Bump HS14 build number to 09 Summary: Update Hotspot 14 build number to b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ad8c8ca4ab0f Author: xdono Date: 2008-12-15 16:55 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/ad8c8ca4ab0f 6785258: Update copyright year Summary: Update copyright for files that have been modified starting July 2008 to Dec 2008 Reviewed-by: katleman, ohair, tbell ! src/cpu/x86/vm/vm_version_x86_32.hpp ! src/cpu/x86/vm/vm_version_x86_64.hpp ! src/os/linux/launcher/java.c ! src/os/linux/launcher/java.h ! src/os/linux/launcher/java_md.c ! src/os/linux/vm/globals_linux.hpp ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java.h ! src/os/solaris/launcher/java_md.c ! src/os/solaris/vm/globals_solaris.hpp ! src/os/windows/vm/globals_windows.hpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.ad ! src/share/tools/IdealGraphVisualizer/Data/src/com/sun/hotspot/igv/data/serialization/XMLWriter.java ! src/share/tools/IdealGraphVisualizer/Difference/src/com/sun/hotspot/igv/difference/Difference.java ! src/share/tools/IdealGraphVisualizer/Filter/src/com/sun/hotspot/igv/filter/CustomFilter.java ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/PropertiesSheet.java ! src/share/tools/IdealGraphVisualizer/Util/src/com/sun/hotspot/igv/util/RangeSliderModel.java ! src/share/tools/IdealGraphVisualizer/View/src/com/sun/hotspot/igv/view/DiagramViewModel.java ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_IR.cpp ! src/share/vm/c1/c1_ValueMap.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psCompactionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/memory/referencePolicy.cpp ! src/share/vm/memory/referencePolicy.hpp ! src/share/vm/memory/tenuredGeneration.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phase.hpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jniCheck.hpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/perfMemory.cpp ! src/share/vm/runtime/perfMemory.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/threadService.hpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/constantTag.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/taskqueue.cpp Changeset: 5e5faba1ac11 Author: xdono Date: 2008-12-18 21:34 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/5e5faba1ac11 Added tag jdk7-b42 for changeset ad8c8ca4ab0f ! .hgtags Changeset: 7b920868b475 Author: coleenp Date: 2008-12-08 15:50 -0500 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/7b920868b475 6773838: There is no calling stack for Compiler thread in hs_err file on x86 Summary: On solaris, the inline assembly wasn't being processed. Added volatile to il file fixed it. Reviewed-by: phh, kvn ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il Changeset: 3ad2b8576c4a Author: coleenp Date: 2008-12-09 09:55 -0500 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/3ad2b8576c4a 6689685: Hotspot crash error message should include libraries version Summary: Print out JDK/JRE version that hotspot knows about. Reviewed-by: kamg, blacklion, acorn, alanb ! src/share/vm/utilities/vmError.cpp Changeset: 7a018855d2f0 Author: jrose Date: 2008-12-08 17:15 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/7a018855d2f0 6779339: turn off LinkWellKnownClasses by default pending further testing Summary: temporarily turn off LinkWellKnownClasses optimization Reviewed-by: never, kvn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/runtime/globals.hpp Changeset: 284d0af00d53 Author: jrose Date: 2008-12-09 12:41 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/284d0af00d53 6771309: debugging AD files is difficult without #line directives in generated code Summary: more and better #line and #define directives in the generated code; ADLC itself accepts #line directives Reviewed-by: never, kvn ! make/linux/adlc_updater ! make/linux/makefiles/adlc.make ! make/solaris/adlc_updater ! make/solaris/makefiles/adlc.make ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/formssel.cpp Changeset: 7b75310e57e2 Author: kvn Date: 2008-12-11 17:20 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/7b75310e57e2 Merge ! src/share/vm/runtime/globals.hpp Changeset: 24fda36852ce Author: coleenp Date: 2008-12-10 15:14 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/24fda36852ce 6727377: VM stack guard pages on Windows should PAGE_READWRITE not PAGE_EXECUTE_READWRITE Summary: Make reguard_stack change access to RW, not execute and use os::protect_memory with the new parameter when change needed to X. Reviewed-by: acorn, jcoomes ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp Changeset: a7fac4381b50 Author: blacklion Date: 2008-12-11 03:22 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/a7fac4381b50 6639341: sometimes contended-exit event comes after contended-entered on another thread Summary: DTrace probe "contended-exit" should be fired before unparking object, or context could be lost. Probe firing was moved to proper place. Reviewed-by: coleenp, kamg ! src/share/vm/runtime/synchronizer.cpp Changeset: 06d2c3204df4 Author: blacklion Date: 2008-12-12 10:19 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/06d2c3204df4 Merge Changeset: d249b360e026 Author: ysr Date: 2008-12-10 23:46 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/d249b360e026 6782457: CMS: Livelock in CompactibleFreeListSpace::block_size() 6736295: SIGSEGV in product jvm, assertion "these are the only valid states during a mark sweep" in fastdebug Summary: Restructured the code in the perm gen allocation retry loop so as to avoid "safepoint-blocking" on locks, in this case the Heap_lock, while holding uninitialized allocated heap storage. Reviewed-by: apetrusenko, iveresov, jcoomes, jmasa, poonam ! src/share/vm/memory/permGen.cpp Changeset: 7d7a7c599c17 Author: jcoomes Date: 2008-12-11 12:05 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/7d7a7c599c17 6578152: fill_region_with_object has usability and safety issues Reviewed-by: apetrusenko, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/includeDB_gc ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/runtime/globals.hpp Changeset: 7c2386d67889 Author: jcoomes Date: 2008-12-11 12:05 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/7c2386d67889 6765745: par compact - allow young gen spaces to be split Reviewed-by: jmasa ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 0f773163217d Author: jcoomes Date: 2008-12-11 12:05 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/0f773163217d 6765954: par compact - stress mode for splitting young gen spaces Reviewed-by: jmasa ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ffe19141e312 Author: jmasa Date: 2008-12-12 15:37 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/ffe19141e312 Merge ! src/share/vm/runtime/globals.hpp Changeset: ac8fe14c93e4 Author: never Date: 2008-12-12 19:53 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/ac8fe14c93e4 6767587: missing call to make_not_entrant after deoptimizing for patching volatiles Reviewed-by: rasbold, kvn ! src/share/vm/c1/c1_Runtime1.cpp Changeset: a738a625039a Author: never Date: 2008-12-12 19:54 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/a738a625039a 6757316: load_constant() produces a wrong long constant, with high a low words swapped Reviewed-by: rasbold, jrose, kvn ! src/share/vm/c1/c1_LIRGenerator.cpp + test/compiler/6757316/Test6757316.java Changeset: 80206b8a9128 Author: never Date: 2008-12-12 19:55 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/80206b8a9128 6758234: if (k cond (a ? : b: c)) returns reversed answer if k is constant and b and c are longs Reviewed-by: kvn, jrose ! src/share/vm/c1/c1_Optimizer.cpp + test/compiler/6758234/Test6758234.java Changeset: 569b3b226089 Author: trims Date: 2008-12-20 09:57 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/569b3b226089 Merge ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: 2494ab195856 Author: swamyv Date: 2008-12-15 13:58 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/2494ab195856 6653214: MemoryPoolMXBean.setUsageThreshold() does not support large heap sizes. Reviewed-by: ysr, mchung ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/services/management.cpp Changeset: dd70dd4c91de Author: kvn Date: 2008-12-16 12:23 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/dd70dd4c91de 6782820: Server VM fails with "unhandled implicit exception in compiled code" Summary: Restore the code which sets a control edge for a klass load node. Reviewed-by: never ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/macro.cpp Changeset: 6c345e1c5992 Author: kvn Date: 2008-12-17 14:09 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/6c345e1c5992 Merge Changeset: 5496e074077f Author: kvn Date: 2008-12-18 11:26 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/5496e074077f 6787050: assert(n->in(0) == 0L,"no control") with UseCompressedOops on sparcv9 Summary: Relax the assert for Sparc. Reviewed-by: never ! src/share/vm/opto/compile.cpp Changeset: eb811d2ef72e Author: kvn Date: 2008-12-18 13:59 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/eb811d2ef72e Merge Changeset: d593294016c3 Author: jcoomes Date: 2008-12-18 01:27 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/d593294016c3 6786195: many nsk.monitoring tests fail with -server -Xcomp Summary: remove Universe::_fillerArrayKlassObj and associated code Reviewed-by: jmasa, tonyp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp Changeset: 234c22e54b98 Author: jcoomes Date: 2008-12-18 10:53 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/234c22e54b98 6784849: par compact - can fail when to_space is non-empty Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: b27c885f75f9 Author: jcoomes Date: 2008-12-18 10:54 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/b27c885f75f9 6786188: par compact - "SplitALot" stress mode should fill to_space Reviewed-by: jmasa, tonyp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp Changeset: 7aadaf46ecd7 Author: jmasa Date: 2008-12-19 12:15 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/7aadaf46ecd7 Merge Changeset: c6065343356f Author: poonam Date: 2008-12-18 17:28 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/c6065343356f 6786340: hs14b09a pit: a lot of tests failed in "-server -Xcomp" on solaris-amd64 using fastdebug bits Summary: Fixes the nsk-jdi PIT failures introduced by fix for 6739363 Reviewed-by: kvn, coleenp ! src/share/vm/runtime/javaCalls.cpp Changeset: 8a25d96bcf08 Author: xlu Date: 2008-12-19 14:40 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/8a25d96bcf08 6784100: getTimeNanos - CAS reduction Summary: Get rid of the CAS loop in getTimeNanos to reduce coherence traffic on Solaris. Reviewed-by: acorn, kvn, ysr ! src/os/solaris/vm/os_solaris.cpp Changeset: ca7d48236048 Author: xlu Date: 2008-12-20 00:45 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/ca7d48236048 Merge Changeset: 26bc4770e671 Author: trims Date: 2008-12-20 09:58 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/26bc4770e671 Merge ! src/share/vm/runtime/javaCalls.cpp Changeset: fc6a5ae3fef5 Author: trims Date: 2008-12-20 09:59 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/fc6a5ae3fef5 6787832: Bump Hotspot build number to 08 Summary: Update the HS14 build number to 08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 2551e5deace8 Author: glewis at misty.eyesbeyond.com Date: 2008-12-28 11:28 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/2551e5deace8 . Merge from the main OpenJDK repository. ! src/share/vm/includeDB_core ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/utilities/macros.hpp ! src/share/vm/utilities/vmError.cpp Changeset: 897a4fb539b6 Author: glewis at misty.eyesbeyond.com Date: 2008-12-28 18:19 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/897a4fb539b6 . Make changes to the BSD specific files analagous to the changes to the Linux specific files. ! make/bsd/adlc_updater ! make/bsd/makefiles/adlc.make ! src/os/bsd/launcher/java.c ! src/os/bsd/launcher/java.h ! src/os/bsd/launcher/java_md.c ! src/os/bsd/vm/globals_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os_cpu/bsd_x86/vm/bsd_x86_32.ad ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp From ekrichardson at gmail.com Sun Dec 28 18:27:25 2008 From: ekrichardson at gmail.com (Eric Richardson) Date: Sun, 28 Dec 2008 18:27:25 -0800 Subject: Power PC Build In-Reply-To: <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> Message-ID: <860cb0120812281827t6b691581i6d32d83d14d637d6@mail.gmail.com> Andrew, On Sun, Dec 28, 2008 at 3:26 PM, Andrew John Hughes < gnu_andrew at member.fsf.org> wrote: > [ccing IcedTea list too] > > 2008/12/28 Greg Lewis : > > G'day Eric, > > > > On Sat, Dec 27, 2008 at 11:12:33PM -0800, Eric Richardson wrote: > >> I was looking into OpenJDK and saw the bsd-port and zero assembly > project > >> and thought It might be possible build jdk6 on PowerPC. After looking > at > >> the bsd-port list I started working on setting up my environment. I have > a > >> G5 based Mac. Here is what I have done so far. > > > > Note that the proprietary JDK6 isn't supported as a JDK for building > IcedTea. IcedTea was originally created so that OpenJDK could be > built without proprietary build tools or plugs. Both are still needed > with the JDK7 tree. It's possible to build 6 without plugs now, but I > guess you can't build it without an existing copy of IcedTea. Of > course, if there is some fix that makes the Mac OS JDK work for you in > building IcedTea, then we are open to patches. But supporting > proprietary JDKs as build tools is not a primary goal of the project > (i.e. no-one's going to be testing it still works on a daily basis). > Your best option would be to try --with-openjdk as a build option. I > know IcedTea7 won't work with a Sun JDK being used as the GCJ JDK at > present, as there are some fixes specific to header files and > differences between gjavah and javah from the JDK. I only have the proprietary JDK 5 to work with AFAIK. The only advantage to making this work on Mac PowerPC is that if someone else needs to do it this way too, at least until there is some installable Free Software version, it leaves a path to get to Open JDK6. > > > > Depending on what you want in terms of a JDK, it might be easier to try > > and port the zero assembler work to the current OpenJDK BSD port. I'd > > like to do this, but I've not seen zero assembler separated out from the > > Iced Tea sources. I believe you need libffi working to get it to work, > > but there are ports for this in MacPorts and in at least the FreeBSD > > ports system (I expect it to be in {Net,Open}BSD as well). > > > > You do libffi for IcedTea's zero support. Should you want to also try > Shark (the zero-assembler JIT support) sometime in the future, you > also need LLVM but this is still a work-in-progress, especially on > 64-bit archs. I haven't quite gotten to this error yet but thanks for this heads up. Currently I'm working past this. checking for main in -ljpeg... no configure: error: "libjpeg not found - try installing libjpeg-devel" sudo apt-get install libjpeg (didn't work) sudo port -v install jpeg (nope) > > > > CC'ing Gary Benson, the zero assembler author. Gary, would it be > > possible to get the zero assembler support as a patch against the > > current OpenJDK 7 sources or could you point out the relevant parts > > of the Iced Tea source? > > > > I guess you'll probably get a response from this from Gary tomorrow, > but my feeling would be that, while it would be possible to provide > zero separately, it's not going to be something that's possible to > support long term as Gary does his work primarily on GNU/Linux within > IcedTea. > > The relevant bits are the ports subdirectory and a number of patches > from the patches subdirectory. You need to comb the Makefile.am a bit > to find these. > > > The other option for getting OpenJDK on Mac OS X / PowerPC is to port > > the BSD support to Iced Tea. Thats certainly doable, but I imagine its > > a bigger job. > > > > IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a > --with-project=bsd option for supporting using the BSD tree in place > of the main JDK7 tree. It just needs testing. I think supporting the > use of BSD as an alternate icedTea build is the better solution long > term. All it really needs is someone will to try building on Mac > OS/BSD and to maintain it long-term by supplying us with patches. > No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK) but > we're certainly open to more contributors and to supporting more > platforms. I'd much prefer this to forking zero support. There are > also other features such as the web plugin, web start support, etc. in > IcedTea that may be useful for BSD and Mac OS X users. I guess I'll wait for someone else to weigh in as I continue down the path I started. > > > >> Installed MacOSX 10.5 > >> Installed XCode 3.1.2 > >> Installed Fink 0.9.0 > >> Installed Mercurial > >> Checked out icetea6 (hg clone http://...) > >> ./autogen.sh > >> ./configure > >> > >> gawk not found > >> apt-get install gawk > >> > >> checking for a GCJ JDK home directory... > >> configure: error: "A GCJ JDK home directory could not be found." > >> > >> ./configure --with-gcj-home=/Library/Java/Home --enable-zero=yes > >> > >> checking for eclipse-ecj.jar... no > >> configure: error: "A ECJ jar was not found." > >> > >> Next error waiting if I fix the above. > >> checking xalan2 jar... no > >> configure: error: "A xalan2 jar was not found." > >> > >> Before I go further, I thought I'd ask if this is going to work at all > using > >> the JDK 5 that comes with MacOSX? > >> Any suggestions on how to proceed? > >> > >> Thanks, > >> Eric > > > >> > > > > > > -- > > Greg Lewis Email : glewis at eyesbeyond.com > > Eyes Beyond Web : http://www.eyesbeyond.com > > Information Technology FreeBSD : glewis at FreeBSD.org > > > > > > > > -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081228/0eb681aa/attachment.html From mvfranz at gmail.com Sun Dec 28 19:52:45 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 28 Dec 2008 22:52:45 -0500 Subject: Power PC Build In-Reply-To: <860cb0120812281654t54005e1el2cfa2b243c155f82@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <860cb0120812281654t54005e1el2cfa2b243c155f82@mail.gmail.com> Message-ID: Eric, This is what I did the last time I attempted to build IcedTea on OS X (Intel). I use MacPorts for the dependencies. At one time I had a Portfile for this, but it got lost in the computer shuffle. Edit configure.ac to change ALSA missing to be a warning instead of an error Installed the following ports: findtuils - use the prefix variant +with_default_names coreutils - use the prefix variant +with_default_names gsed - use the prefix variant +with_default_names nawk -- not needed if openjdk/jdk/make/common/shared/Defs-utils.gmk is patched eclipse-ecj32 jpeg xercesj xalanj freetype export LDFLAGS='-L/opt/local/lib' maybe this too: export PKG_CONFIG_PATH='/opt/local/lib/pkgconfig:/usr/X11R6/lib/pkgconfig' I used OpenJDK to bootstrap Icedtea6 - previously I used Apple's JDK 6. ./configure --enable-zero --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar --with-libgcj-jar=/Volumes/Leopard/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/jre/lib/rt.jar --with-xalan2-jar=/opt/local/share/java/xalan.jar --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar --without-rhino --disable-liveconnect --with-gcj-home=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/ then make I was taking things from the OpenJDK 7 BSD port to get around missing make files, but mixing OpenJDK 6 and OpenJDK 7 is probably not a good idea. Michael On Sun, Dec 28, 2008 at 7:54 PM, Eric Richardson wrote: > Hi Michael, > > On Sun, Dec 28, 2008 at 8:52 AM, Michael Franz wrote: > >> Eric, >> >> I have looked at compiling IcedTea for OS X prior to the BSD port being >> public. I was not successful. I use Macports and had some of the necessary >> dependencies added to it (eclipse-ecj). I also only have Intel macs so I >> can use the OpenJDK BSD port to bootstrap. > > > Thanks for this MacPorts tip as this helped me past my eclipse-ecj hurdle. > > >> >> I don't have my notes handy, but I was using Java 6 (at the time Apple's >> Java 6 was not complete) and had some issues with compling some classes. I >> tried to get Red Hat's modified gcc/gcj but it would not compile. GCC 4.3 >> was not released yet, but I think it is now. Gcc 4.3 should work as an >> alternative - no guarentees. Will Java 5 work? I don't know. >> >> I was recently looking at using the zero port in Icedtea, but never >> completed the build process either. > > > I read some more on the IceTea site and it looks like this should be > possible. > > >> >> I can post my configure script when I have access if you are still >> interested. >> >> Michael > > > Eric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081228/a8593113/attachment.html From mvfranz at gmail.com Sun Dec 28 20:15:11 2008 From: mvfranz at gmail.com (Michael Franz) Date: Sun, 28 Dec 2008 23:15:11 -0500 Subject: hg: bsd-port/bsd-port/hotspot: 59 new changesets In-Reply-To: <20081229022222.95DB6DFB0@hg.openjdk.java.net> References: <20081229022222.95DB6DFB0@hg.openjdk.java.net> Message-ID: Greg, Should the OS X build work for 32 and 64 bit after these commits? I am having build failures on both. Michael On Sun, Dec 28, 2008 at 9:20 PM, wrote: [body removed] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081228/9881a2f8/attachment.html From Xiaobin.Lu at Sun.COM Sun Dec 28 20:53:58 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Sun, 28 Dec 2008 20:53:58 -0800 Subject: hg: bsd-port/bsd-port/hotspot: 59 new changesets In-Reply-To: References: <20081229022222.95DB6DFB0@hg.openjdk.java.net> Message-ID: <495857E6.2000907@Sun.COM> I believe my fix to the intptr_t problem hasn't been integrated to the main hotspot repository yet even though it is in the runtime sub-repository, therefore, the 32 bit build should still be problematic. -Xiaobin Michael Franz wrote: > Greg, > > Should the OS X build work for 32 and 64 bit after these commits? I > am having build failures on both. > > Michael > > On Sun, Dec 28, 2008 at 9:20 PM, > wrote: > [body removed] > ------------------------------------------------------------------------ > > > From ekrichardson at gmail.com Sun Dec 28 23:09:07 2008 From: ekrichardson at gmail.com (Eric Richardson) Date: Sun, 28 Dec 2008 23:09:07 -0800 Subject: Power PC Build In-Reply-To: References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <860cb0120812281654t54005e1el2cfa2b243c155f82@mail.gmail.com> Message-ID: <860cb0120812282309k394408baj2680c888937b8d81@mail.gmail.com> Michael, I know it is not generally good to cross post. Should this be targeted towards distro-pkg-dev? Since I'm new to this I really want to stay in good standing. On Sun, Dec 28, 2008 at 7:52 PM, Michael Franz wrote: > Eric, > > This is what I did the last time I attempted to build IcedTea on OS X > (Intel). > > I use MacPorts for the dependencies. At one time I had a Portfile for > this, but it got lost in the computer shuffle. > > Edit configure.ac to change ALSA missing to be a warning instead of an > error > Installed the following ports: > findtuils - use the prefix variant +with_default_names > coreutils - use the prefix variant +with_default_names > gsed - use the prefix variant +with_default_names > nawk -- not needed if openjdk/jdk/make/common/shared/Defs-utils.gmk is > patched > eclipse-ecj32 > jpeg > xercesj > xalanj > freetype > > export LDFLAGS='-L/opt/local/lib' I got past most of the dependencies so far. I used the LDFLAGS and it works to find the added libraries. (was thinking LD_LIBRARY_PATH) Now I found something a breaking which is on line 285 of configure.ac ./configure: line 11156: syntax error near unexpected token `XPROTO,' ./configure: line 11156: `PKG_CHECK_MODULES(XPROTO, xproto,XPROTO_FOUND=yes,XPROTO_FOUND=no)' return from the shell, echo $? 2 from config.log, configure: exit 258 I don't see anything obvious and am really not all that familiar yet with these configuration scripts. > maybe this too: export > PKG_CONFIG_PATH='/opt/local/lib/pkgconfig:/usr/X11R6/lib/pkgconfig' > > I used OpenJDK to bootstrap Icedtea6 - previously I used Apple's JDK 6. > > ./configure --enable-zero > --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar > --with-libgcj-jar=/Volumes/Leopard/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/jre/lib/rt.jar > --with-xalan2-jar=/opt/local/share/java/xalan.jar > --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar > --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar --without-rhino > --disable-liveconnect > --with-gcj-home=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/ > > then make > > I was taking things from the OpenJDK 7 BSD port to get around missing make > files, but mixing OpenJDK 6 and OpenJDK 7 is probably not a good idea. > > Michael > > > On Sun, Dec 28, 2008 at 7:54 PM, Eric Richardson wrote: > >> Hi Michael, >> >> On Sun, Dec 28, 2008 at 8:52 AM, Michael Franz wrote: >> >>> Eric, >>> >>> I have looked at compiling IcedTea for OS X prior to the BSD port being >>> public. I was not successful. I use Macports and had some of the necessary >>> dependencies added to it (eclipse-ecj). I also only have Intel macs so I >>> can use the OpenJDK BSD port to bootstrap. >> >> >> Thanks for this MacPorts tip as this helped me past my eclipse-ecj hurdle. >> >> >>> >>> I don't have my notes handy, but I was using Java 6 (at the time Apple's >>> Java 6 was not complete) and had some issues with compling some classes. I >>> tried to get Red Hat's modified gcc/gcj but it would not compile. GCC 4.3 >>> was not released yet, but I think it is now. Gcc 4.3 should work as an >>> alternative - no guarentees. Will Java 5 work? I don't know. >>> >>> I was recently looking at using the zero port in Icedtea, but never >>> completed the build process either. >> >> >> I read some more on the IceTea site and it looks like this should be >> possible. >> >> >>> >>> I can post my configure script when I have access if you are still >>> interested. >>> >>> Michael >> >> >> Eric >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081228/7500c4c9/attachment.html From gnu_andrew at member.fsf.org Mon Dec 29 00:17:35 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 29 Dec 2008 08:17:35 +0000 Subject: Power PC Build In-Reply-To: References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <860cb0120812281654t54005e1el2cfa2b243c155f82@mail.gmail.com> Message-ID: <17c6771e0812290017m3b3e86e4ke0fcf7037a61b97a@mail.gmail.com> 2008/12/29 Michael Franz : > Eric, > > This is what I did the last time I attempted to build IcedTea on OS X > (Intel). > > I use MacPorts for the dependencies. At one time I had a Portfile for this, > but it got lost in the computer shuffle. > > Edit configure.ac to change ALSA missing to be a warning instead of an error > Installed the following ports: > findtuils - use the prefix variant +with_default_names > coreutils - use the prefix variant +with_default_names > gsed - use the prefix variant +with_default_names > nawk -- not needed if openjdk/jdk/make/common/shared/Defs-utils.gmk is > patched > eclipse-ecj32 > jpeg > xercesj > xalanj > freetype > > export LDFLAGS='-L/opt/local/lib' > maybe this too: export > PKG_CONFIG_PATH='/opt/local/lib/pkgconfig:/usr/X11R6/lib/pkgconfig' > > I used OpenJDK to bootstrap Icedtea6 - previously I used Apple's JDK 6. > > ./configure --enable-zero > --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar > --with-libgcj-jar=/Volumes/Leopard/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/jre/lib/rt.jar > --with-xalan2-jar=/opt/local/share/java/xalan.jar > --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar > --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar --without-rhino > --disable-liveconnect > --with-gcj-home=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/ > --with-gcj-home is really designed for a Classpath JDK, so there's no guarantee that will always work with anything else. --with-libgcj-jar has now been dropped; as can be seen in your example, it's derivable from --with-gcj-home. > then make > > I was taking things from the OpenJDK 7 BSD port to get around missing make > files, but mixing OpenJDK 6 and OpenJDK 7 is probably not a good idea. > There's not much other option given that the BSD tree is 7 only, unless you want to use IcedTea7. > Michael > > On Sun, Dec 28, 2008 at 7:54 PM, Eric Richardson > wrote: >> >> Hi Michael, >> >> On Sun, Dec 28, 2008 at 8:52 AM, Michael Franz wrote: >>> >>> Eric, >>> >>> I have looked at compiling IcedTea for OS X prior to the BSD port being >>> public. I was not successful. I use Macports and had some of the necessary >>> dependencies added to it (eclipse-ecj). I also only have Intel macs so I >>> can use the OpenJDK BSD port to bootstrap. >> >> Thanks for this MacPorts tip as this helped me past my eclipse-ecj hurdle. >> >>> >>> >>> I don't have my notes handy, but I was using Java 6 (at the time Apple's >>> Java 6 was not complete) and had some issues with compling some classes. I >>> tried to get Red Hat's modified gcc/gcj but it would not compile. GCC 4.3 >>> was not released yet, but I think it is now. Gcc 4.3 should work as an >>> alternative - no guarentees. Will Java 5 work? I don't know. >>> >>> I was recently looking at using the zero port in Icedtea, but never >>> completed the build process either. >> >> >> I read some more on the IceTea site and it looks like this should be >> possible. >> >>> >>> >>> I can post my configure script when I have access if you are still >>> interested. >>> >>> Michael >> >> Eric > > > > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Dec 29 00:18:20 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 29 Dec 2008 08:18:20 +0000 Subject: Power PC Build In-Reply-To: <860cb0120812282309k394408baj2680c888937b8d81@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <860cb0120812281654t54005e1el2cfa2b243c155f82@mail.gmail.com> <860cb0120812282309k394408baj2680c888937b8d81@mail.gmail.com> Message-ID: <17c6771e0812290018h2806dfa9i7ac70ff126666a75@mail.gmail.com> 2008/12/29 Eric Richardson : > Michael, > > I know it is not generally good to cross post. Should this be targeted > towards distro-pkg-dev? Since I'm new to this I really want to stay in good > standing. > > On Sun, Dec 28, 2008 at 7:52 PM, Michael Franz wrote: >> >> Eric, >> >> This is what I did the last time I attempted to build IcedTea on OS X >> (Intel). >> >> I use MacPorts for the dependencies. At one time I had a Portfile for >> this, but it got lost in the computer shuffle. >> >> Edit configure.ac to change ALSA missing to be a warning instead of an >> error >> Installed the following ports: >> findtuils - use the prefix variant +with_default_names >> coreutils - use the prefix variant +with_default_names >> gsed - use the prefix variant +with_default_names >> nawk -- not needed if openjdk/jdk/make/common/shared/Defs-utils.gmk is >> patched >> eclipse-ecj32 >> jpeg >> xercesj >> xalanj >> freetype >> >> export LDFLAGS='-L/opt/local/lib' > > > I got past most of the dependencies so far. > > I used the LDFLAGS and it works to find the added libraries. (was thinking > LD_LIBRARY_PATH) > > Now I found something a breaking which is on line 285 of configure.ac > > ./configure: line 11156: syntax error near unexpected token `XPROTO,' > ./configure: line 11156: `PKG_CHECK_MODULES(XPROTO, > xproto,XPROTO_FOUND=yes,XPROTO_FOUND=no)' > > return from the shell, echo $? 2 > from config.log, configure: exit 258 > > I don't see anything obvious and am really not all that familiar yet with > these configuration scripts. > This line shouldn't be in the configuration script. Something went wrong when you ran ./autogen.sh. >> >> maybe this too: export >> PKG_CONFIG_PATH='/opt/local/lib/pkgconfig:/usr/X11R6/lib/pkgconfig' >> >> I used OpenJDK to bootstrap Icedtea6 - previously I used Apple's JDK 6. >> >> ./configure --enable-zero >> --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar >> --with-libgcj-jar=/Volumes/Leopard/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/jre/lib/rt.jar >> --with-xalan2-jar=/opt/local/share/java/xalan.jar >> --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar >> --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar --without-rhino >> --disable-liveconnect >> --with-gcj-home=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/ >> >> then make >> >> I was taking things from the OpenJDK 7 BSD port to get around missing make >> files, but mixing OpenJDK 6 and OpenJDK 7 is probably not a good idea. >> >> Michael >> >> On Sun, Dec 28, 2008 at 7:54 PM, Eric Richardson >> wrote: >>> >>> Hi Michael, >>> >>> On Sun, Dec 28, 2008 at 8:52 AM, Michael Franz wrote: >>>> >>>> Eric, >>>> >>>> I have looked at compiling IcedTea for OS X prior to the BSD port being >>>> public. I was not successful. I use Macports and had some of the necessary >>>> dependencies added to it (eclipse-ecj). I also only have Intel macs so I >>>> can use the OpenJDK BSD port to bootstrap. >>> >>> Thanks for this MacPorts tip as this helped me past my eclipse-ecj >>> hurdle. >>> >>>> >>>> >>>> I don't have my notes handy, but I was using Java 6 (at the time Apple's >>>> Java 6 was not complete) and had some issues with compling some classes. I >>>> tried to get Red Hat's modified gcc/gcj but it would not compile. GCC 4.3 >>>> was not released yet, but I think it is now. Gcc 4.3 should work as an >>>> alternative - no guarentees. Will Java 5 work? I don't know. >>>> >>>> I was recently looking at using the zero port in Icedtea, but never >>>> completed the build process either. >>> >>> >>> I read some more on the IceTea site and it looks like this should be >>> possible. >>> >>>> >>>> >>>> I can post my configure script when I have access if you are still >>>> interested. >>>> >>>> Michael >>> >>> Eric >> > > > > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From glewis at eyesbeyond.com Mon Dec 29 08:47:06 2008 From: glewis at eyesbeyond.com (Greg Lewis) Date: Mon, 29 Dec 2008 08:47:06 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <4957F135.3040300@Sun.COM> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> <494FE536.1040102@Sun.COM> <20081226072429.GA69479@misty.eyesbeyond.com> <49548922.80703@Sun.COM> <20081226172736.GA42840@misty.eyesbeyond.com> <20081228082926.GA77650@misty.eyesbeyond.com> <20081228205541.GA11757@misty.eyesbeyond.com> <4957F135.3040300@Sun.COM> Message-ID: <20081229164706.GA52523@misty.eyesbeyond.com> G'day Xiaobin, On Sun, Dec 28, 2008 at 01:35:49PM -0800, Xiaobin Lu wrote: > I tested your patch and it worked fine on 32 & 64 bit build. However, we > still need the patch for src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp. > The patch looks like the following: > > diff -r de4c58dbee8f src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp > --- a/src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp Wed Nov 26 > 05:05:13 2008 -0800 > +++ b/src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp Wed Dec 17 > 21:06:49 2008 -0800 > @@ -32,9 +32,9 @@ > > #if defined(AMD64) > # if defined(__APPLE__) > -# define bswap16(x) OSSwapInt16(x) > -# define bswap32(x) OSSwapInt32(x) > -# define bswap64(x) OSSwapInt64(x) > +# define bswap_16(x) OSSwapInt16(x) > +# define bswap_32(x) OSSwapInt32(x) > +# define bswap_64(x) OSSwapInt64(x) > # elif defined(__OpenBSD__) > # define bswap_16(x) swap16(x) > # define bswap_32(x) swap32(x) > > You may want to check in the above as well. By the way, I've already > integrated my fix to solve the intptr_t and int32_t into hotspot-rt > repository (http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot). It will > probably take another week for the fix to show up in the hotspot main > repository. Yep, we do need that too. Can you please check it in? I'll check my change in too and we should have a working 64 bit build. It sounds like the 32 bit build will be fixed once your other change bubbles up into the main tree and we do a merge. BTW, how are you passing in -m64 to the build on Mac OS X? > Greg Lewis wrote: > > On Sun, Dec 28, 2008 at 12:29:26AM -0800, Greg Lewis wrote: > > > >> On Fri, Dec 26, 2008 at 09:27:36AM -0800, Greg Lewis wrote: > >> > >>> On Thu, Dec 25, 2008 at 11:34:58PM -0800, Xiaobin Lu wrote: > >>> > >>>> So with my openjdk id, I can commit the changes without extra permission? > >>>> > >>> I think I should have looked harder at the change first, sorry. I tried > >>> compiling with that change in and it broke the i386 build :(. I'm looking > >>> at things side by side with the current Linux code to try and get the > >>> braces and #ifdef's right, but I have to say this part of the code is > >>> becoming quite confusing with the proliferation of preprocessor > >>> conditionals. > >>> > >>> I hope to have something later today that you can test on Mac OS X. > >>> > >> Instead I shovelled snow/ice for a couple of days so we could get out of > >> our house to the main roads :). > >> > >> Anyway, attached is a patch. Its not yet compile tested, I've got the > >> compile started however and will check in the morning. Please give it > >> a try on Mac OS X. Basically it looks like the special handling for > >> 64 bit Mac OS X was half merged into the x86 handling. > >> > > > > Oops, as Kurt pointed out I forgot to attach the patch... Trying again. > > > > > >>>> Greg Lewis wrote: > >>>> > >>>>> G'day Xiaobin, > >>>>> > >>>>> On Mon, Dec 22, 2008 at 11:06:30AM -0800, Xiaobin Lu wrote: > >>>>> > >>>>> > >>>>>> I am attaching the patch to make the VM build pass on Mac OS 64 bit. > >>>>>> Here is some explanation on the change: > >>>>>> > >>>>>> bytes_bsd_x86.inline.cpp: > >>>>>> > >>>>>> Change bswap16(x) to bswap_16(x) and the similar, I believe there was a > >>>>>> typo for this. When some ported this to Apple platform, they missed a > >>>>>> underscore. > >>>>>> > >>>>>> os_bsd_x86.cpp > >>>>>> > >>>>>> There was a "}" missing for 64 bit build. > >>>>>> > >>>>>> > >>>>> Thats a lot clearer when I use diff -b :). > >>>>> > >>>>> > >>>>> > >>>>>> Other changes to make the build pass will be covered by my fix to > >>>>>> 6787106 which I am going to put back to open JDK 7 tree soon. > >>>>>> > >>>>>> Please help me review the patch and feel free to let me know if there > >>>>>> was anything wrong. > >>>>>> > >>>>>> > >>>>> Looks good to me -- I say go ahead and commit it. > >>>>> > >>>>> > >>>>> > >>>>>> Greg Lewis wrote: > >>>>>> > >>>>>> > >>>>>>> G'day Xiaobin, > >>>>>>> > >>>>>>> On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> I am attaching the patch for building 64 bit VM. They are BSD specific > >>>>>>>> files. Would someone review it and help me check it in? > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Sure. Can you comment a little on the changes to > >>>>>>> src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is > >>>>>>> bigger than the changes if that makes sense (i.e. there are some whitespace > >>>>>>> changes due to control flow changes which are hiding those). > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>>> > >>>>> > >>> -- > >>> Greg Lewis Email : glewis at eyesbeyond.com > >>> Eyes Beyond Web : http://www.eyesbeyond.com > >>> Information Technology FreeBSD : glewis at FreeBSD.org > >>> > >> -- > >> Greg Lewis Email : glewis at eyesbeyond.com > >> Eyes Beyond Web : http://www.eyesbeyond.com > >> Information Technology FreeBSD : glewis at FreeBSD.org > >> > > > > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From glewis at eyesbeyond.com Mon Dec 29 09:49:48 2008 From: glewis at eyesbeyond.com (glewis at eyesbeyond.com) Date: Mon, 29 Dec 2008 17:49:48 +0000 Subject: hg: bsd-port/bsd-port/hotspot: . Fix the signal handling code for 64 bit builds on Mac OS X. Message-ID: <20081229174950.AE5DAD03D@hg.openjdk.java.net> Changeset: 07b7530c9f18 Author: glewis at misty.eyesbeyond.com Date: 2008-12-29 09:49 -0800 URL: http://hg.openjdk.java.net/bsd-port/bsd-port/hotspot/rev/07b7530c9f18 . Fix the signal handling code for 64 bit builds on Mac OS X. . Change a comment to make sense. ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp From ekrichardson at gmail.com Mon Dec 29 10:20:37 2008 From: ekrichardson at gmail.com (Eric Richardson) Date: Mon, 29 Dec 2008 10:20:37 -0800 Subject: Power PC Build In-Reply-To: <17c6771e0812290017m3b3e86e4ke0fcf7037a61b97a@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <860cb0120812281654t54005e1el2cfa2b243c155f82@mail.gmail.com> <17c6771e0812290017m3b3e86e4ke0fcf7037a61b97a@mail.gmail.com> Message-ID: <860cb0120812291020s6d1346fdq88c7b6330413c7c0@mail.gmail.com> Andrew, On Mon, Dec 29, 2008 at 12:17 AM, Andrew John Hughes < gnu_andrew at member.fsf.org> wrote: > clip > > I used OpenJDK to bootstrap Icedtea6 - previously I used Apple's JDK 6. > > > > ./configure --enable-zero > > --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar > > > --with-libgcj-jar=/Volumes/Leopard/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/jre/lib/rt.jar > > --with-xalan2-jar=/opt/local/share/java/xalan.jar > > --with-xalan2-serializer-jar=/opt/local/share/java/serializer.jar > > --with-xerces2-jar=/opt/local/share/java/xercesImpl.jar --without-rhino > > --disable-liveconnect > > > --with-gcj-home=/Users/mfranz/developer/openjdk-bsd/bin/openjdk7-darwin-i386-20080820/ > > > > --with-gcj-home is really designed for a Classpath JDK, so there's no > guarantee that will always work with anything else. --with-libgcj-jar > has now been dropped; as can be seen in your example, it's derivable > from --with-gcj-home. I tried to use the other -home options and it complained, but with the gcj it let me pass. > > > > then make > > > > I was taking things from the OpenJDK 7 BSD port to get around missing > make > > files, but mixing OpenJDK 6 and OpenJDK 7 is probably not a good idea. > > > > There's not much other option given that the BSD tree is 7 only, > unless you want to use IcedTea7. Well, I sort of wanted to work on a jdk 6 as that is sort of the current one and who knows when 7 will go prime time. So I guess nobody is going to want to back port that work to open jdk 6? But do I need a jdk6 environment to work the BSD 7 work? If so perhaps I could try IcePick to at least get the jdk tools. To my knowledge, the only jdk on PowerPC Mac is the Apple 1.5 version. > > > Michael > > > > On Sun, Dec 28, 2008 at 7:54 PM, Eric Richardson > > > wrote: > >> > >> Hi Michael, > >> > >> On Sun, Dec 28, 2008 at 8:52 AM, Michael Franz > wrote: > >>> > >>> Eric, > >>> > >>> I have looked at compiling IcedTea for OS X prior to the BSD port being > >>> public. I was not successful. I use Macports and had some of the > necessary > >>> dependencies added to it (eclipse-ecj). I also only have Intel macs so > I > >>> can use the OpenJDK BSD port to bootstrap. > >> > >> Thanks for this MacPorts tip as this helped me past my eclipse-ecj > hurdle. > >> > >>> > >>> > >>> I don't have my notes handy, but I was using Java 6 (at the time > Apple's > >>> Java 6 was not complete) and had some issues with compling some > classes. I > >>> tried to get Red Hat's modified gcc/gcj but it would not compile. GCC > 4.3 > >>> was not released yet, but I think it is now. Gcc 4.3 should work as an > >>> alternative - no guarentees. Will Java 5 work? I don't know. > >>> > >>> I was recently looking at using the zero port in Icedtea, but never > >>> completed the build process either. > >> > >> > >> I read some more on the IceTea site and it looks like this should be > >> possible. > >> > >>> > >>> > >>> I can post my configure script when I have access if you are still > >>> interested. > >>> > >>> Michael > >> > >> Eric > > > > > > > > > > > > > > -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081229/aac38fc1/attachment.html From mvfranz at gmail.com Mon Dec 29 15:57:22 2008 From: mvfranz at gmail.com (Michael Franz) Date: Mon, 29 Dec 2008 18:57:22 -0500 Subject: Power PC Build In-Reply-To: <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> Message-ID: Andrew, On Sun, Dec 28, 2008 at 6:26 PM, Andrew John Hughes < gnu_andrew at member.fsf.org> wrote: > > IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a > --with-project=bsd option for supporting using the BSD tree in place > of the main JDK7 tree. It just needs testing. I think supporting the > use of BSD as an alternate icedTea build is the better solution long > term. All it really needs is someone will to try building on Mac > OS/BSD and to maintain it long-term by supplying us with patches. > No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK) but > we're certainly open to more contributors and to supporting more > platforms. I'd much prefer this to forking zero support. There are > also other features such as the web plugin, web start support, etc. in > IcedTea that may be useful for BSD and Mac OS X users. > I made a quick attempt at building icedtea7 on OS X. The autogen.sh fails with the following: onfigure.ac:4: installing `./config.guess' configure.ac:4: installing `./config.sub' configure.ac:2: installing `./install-sh' Makefile.am:1304: variable `PULSEAUDIO_SOURCES' is defined but no program or Makefile.am:1304: library has `PULSEAUDIO' as canonic name (possible typo) Makefile.am:1227: variable `JTREG_SOURCES' is defined but no program or Makefile.am:1227: library has `JTREG' as canonic name (possible typo) Also, I was not able to find IcedTea7 specific instructions. Are there any? Michael > > -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081229/83f51f9c/attachment.html From ekrichardson at gmail.com Mon Dec 29 20:44:11 2008 From: ekrichardson at gmail.com (Eric Richardson) Date: Mon, 29 Dec 2008 20:44:11 -0800 Subject: Power PC Build In-Reply-To: References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> Message-ID: <860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com> Michael, On Mon, Dec 29, 2008 at 3:57 PM, Michael Franz wrote: > Andrew, > > On Sun, Dec 28, 2008 at 6:26 PM, Andrew John Hughes < > gnu_andrew at member.fsf.org> wrote: > > >> >> IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a >> --with-project=bsd option for supporting using the BSD tree in place >> of the main JDK7 tree. It just needs testing. I think supporting the >> use of BSD as an alternate icedTea build is the better solution long >> term. All it really needs is someone will to try building on Mac >> OS/BSD and to maintain it long-term by supplying us with patches. >> No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK) but >> we're certainly open to more contributors and to supporting more >> platforms. I'd much prefer this to forking zero support. There are >> also other features such as the web plugin, web start support, etc. in >> IcedTea that may be useful for BSD and Mac OS X users. >> > > I made a quick attempt at building icedtea7 on OS X. The autogen.sh fails > with the following: > onfigure.ac:4: installing `./config.guess' > configure.ac:4: installing `./config.sub' > configure.ac:2: installing `./install-sh' > Makefile.am:1304: variable `PULSEAUDIO_SOURCES' is defined but no program > or > Makefile.am:1304: library has `PULSEAUDIO' as canonic name (possible typo) > Makefile.am:1227: variable `JTREG_SOURCES' is defined but no program or > Makefile.am:1227: library has `JTREG' as canonic name (possible typo) > > Also, I was not able to find IcedTea7 specific instructions. Are there > any? > > Michael > > I got this same error but tried configure anyway ./configure --with-openjdk-home=/Library/Java/Home --enable-zero=yes --with-project=bsd --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar --with-alt-jar=/System/LibrarFrameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar checking for libgcj-4.3.*.jar... configure: error: "A LIBGCJ jar was not found." I thought maybe I could clear this problem by trying to compile gcj34(from MacPorts) using gcc42? The gcc 4.0.1 wouldn't do it and I saw a post on http://trac.macports.org/ticket/9730 that said wontfix the gcj34 port because pdftk compiles just fine on Intel and PowerPC Macs using gcc42, which has been the default for pdftk since r25014. Would this help me out for Icetea7 or some other path or is this a dead end? What tools (gcc, gcj etc) and versions would be good to start with? Eric > > >> >> -- >> Andrew :-) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081229/7bb69722/attachment.html From ekrichardson at gmail.com Mon Dec 29 20:55:40 2008 From: ekrichardson at gmail.com (Eric Richardson) Date: Mon, 29 Dec 2008 20:55:40 -0800 Subject: Power PC Build In-Reply-To: <17c6771e0812290018h2806dfa9i7ac70ff126666a75@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <860cb0120812281654t54005e1el2cfa2b243c155f82@mail.gmail.com> <860cb0120812282309k394408baj2680c888937b8d81@mail.gmail.com> <17c6771e0812290018h2806dfa9i7ac70ff126666a75@mail.gmail.com> Message-ID: <860cb0120812292055k73e7e68cv5362b3e6b1feeb1f@mail.gmail.com> Andrew, On Mon, Dec 29, 2008 at 12:18 AM, Andrew John Hughes < gnu_andrew at member.fsf.org> wrote: > 2008/12/29 Eric Richardson : > > Michael, > > > > I know it is not generally good to cross post. Should this be targeted > > towards distro-pkg-dev? Since I'm new to this I really want to stay in > good > > standing. > > > > On Sun, Dec 28, 2008 at 7:52 PM, Michael Franz > wrote: > >> > >> Eric, > >> > >> This is what I did the last time I attempted to build IcedTea on OS X > >> (Intel). > >> > >> I use MacPorts for the dependencies. At one time I had a Portfile for > >> this, but it got lost in the computer shuffle. > >> > >> Edit configure.ac to change ALSA missing to be a warning instead of an > >> error > >> Installed the following ports: > >> findtuils - use the prefix variant +with_default_names > >> coreutils - use the prefix variant +with_default_names > >> gsed - use the prefix variant +with_default_names > >> nawk -- not needed if openjdk/jdk/make/common/shared/Defs-utils.gmk is > >> patched > >> eclipse-ecj32 > >> jpeg > >> xercesj > >> xalanj > >> freetype > >> > >> export LDFLAGS='-L/opt/local/lib' > > > > > > I got past most of the dependencies so far. > > > > I used the LDFLAGS and it works to find the added libraries. (was > thinking > > LD_LIBRARY_PATH) > > > > Now I found something a breaking which is on line 285 of configure.ac > > > > ./configure: line 11156: syntax error near unexpected token `XPROTO,' > > ./configure: line 11156: `PKG_CHECK_MODULES(XPROTO, > > xproto,XPROTO_FOUND=yes,XPROTO_FOUND=no)' > > > > return from the shell, echo $? 2 > > from config.log, configure: exit 258 > > > > I don't see anything obvious and am really not all that familiar yet with > > these configuration scripts. > > > > This line shouldn't be in the configuration script. Something went > wrong when you ran ./autogen.sh. I ran autoconf -v new-host:icedtea6 eric$ ./autogen.sh autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: autoconf --force autoreconf: configure.ac: not using Autoheader autoreconf: running: automake --add-missing --copy --force-missing autoreconf: Leaving directory `.' Do you know if the line can be removed from configure.ac? -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081229/6f2e5d7b/attachment.html From gnu_andrew at member.fsf.org Mon Dec 29 23:26:51 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 30 Dec 2008 07:26:51 +0000 Subject: Power PC Build In-Reply-To: References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> Message-ID: <17c6771e0812292326w123d6155p3e5191de14793714@mail.gmail.com> 2008/12/29 Michael Franz : > Andrew, > > On Sun, Dec 28, 2008 at 6:26 PM, Andrew John Hughes > wrote: > >> >> IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a >> --with-project=bsd option for supporting using the BSD tree in place >> of the main JDK7 tree. It just needs testing. I think supporting the >> use of BSD as an alternate icedTea build is the better solution long >> term. All it really needs is someone will to try building on Mac >> OS/BSD and to maintain it long-term by supplying us with patches. >> No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK) but >> we're certainly open to more contributors and to supporting more >> platforms. I'd much prefer this to forking zero support. There are >> also other features such as the web plugin, web start support, etc. in >> IcedTea that may be useful for BSD and Mac OS X users. > > I made a quick attempt at building icedtea7 on OS X. The autogen.sh fails > with the following: > onfigure.ac:4: installing `./config.guess' > configure.ac:4: installing `./config.sub' > configure.ac:2: installing `./install-sh' > Makefile.am:1304: variable `PULSEAUDIO_SOURCES' is defined but no program or > Makefile.am:1304: library has `PULSEAUDIO' as canonic name (possible typo) > Makefile.am:1227: variable `JTREG_SOURCES' is defined but no program or > Makefile.am:1227: library has `JTREG' as canonic name (possible typo) > These are just warnings. I should probably use different names for these variables though so automake doesn't make the wrong assumption about them. > Also, I was not able to find IcedTea7 specific instructions. Are there any? > INSTALL and README in the IcedTea7 sources. Most things are the same; IcedTea6 regularly gets merged over to 7. The main difference is 7 supports --with-project=x so you can build the bsd ports tree, nio2, caciocavallo, etc. > Michael > > >> >> -- >> Andrew :-) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >> > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From gnu_andrew at member.fsf.org Mon Dec 29 23:30:29 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 30 Dec 2008 07:30:29 +0000 Subject: Power PC Build In-Reply-To: <860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> <860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com> Message-ID: <17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com> 2008/12/30 Eric Richardson : > Michael, > > On Mon, Dec 29, 2008 at 3:57 PM, Michael Franz wrote: >> >> Andrew, >> >> On Sun, Dec 28, 2008 at 6:26 PM, Andrew John Hughes >> wrote: >> >>> >>> IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a >>> --with-project=bsd option for supporting using the BSD tree in place >>> of the main JDK7 tree. It just needs testing. I think supporting the >>> use of BSD as an alternate icedTea build is the better solution long >>> term. All it really needs is someone will to try building on Mac >>> OS/BSD and to maintain it long-term by supplying us with patches. >>> No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK) but >>> we're certainly open to more contributors and to supporting more >>> platforms. I'd much prefer this to forking zero support. There are >>> also other features such as the web plugin, web start support, etc. in >>> IcedTea that may be useful for BSD and Mac OS X users. >> >> I made a quick attempt at building icedtea7 on OS X. The autogen.sh fails >> with the following: >> onfigure.ac:4: installing `./config.guess' >> configure.ac:4: installing `./config.sub' >> configure.ac:2: installing `./install-sh' >> Makefile.am:1304: variable `PULSEAUDIO_SOURCES' is defined but no program >> or >> Makefile.am:1304: library has `PULSEAUDIO' as canonic name (possible typo) >> Makefile.am:1227: variable `JTREG_SOURCES' is defined but no program or >> Makefile.am:1227: library has `JTREG' as canonic name (possible typo) >> >> Also, I was not able to find IcedTea7 specific instructions. Are there >> any? >> >> Michael >> > > I got this same error but tried configure anyway > > ./configure --with-openjdk-home=/Library/Java/Home --enable-zero=yes > --with-project=bsd --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar > --with-alt-jar=/System/LibrarFrameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar > > checking for libgcj-4.3.*.jar... > configure: error: "A LIBGCJ jar was not found." > Either use an OpenJDK/IcedTea build by adding --with-openjdk or specify --with-libgcj-jar to point to rt.jar. As I said in my previous email though, the libgcj build will not work with a non-Classpath/GCJ build environment. (--with-libgcj-jar is gone from IcedTea6, it will go from 7 when we next merge). > I thought maybe I could clear this problem by trying to compile gcj34(from > MacPorts) using gcc42? The gcc 4.0.1 wouldn't do it and I saw a post > on http://trac.macports.org/ticket/9730 that said > How would an ancient gcj help? You want 4.3 > wontfix the gcj34 port because pdftk compiles just fine on Intel and PowerPC > Macs using gcc42, which has been the default for pdftk since r25014. > > Would this help me out for Icetea7 or some other path or is this a dead end? > > What tools (gcc, gcj etc) and versions would be good to start with? > Building GNU Classpath + CACAO might be the easiest option, then use that to build IcedTea. Or build gcc 4.3 with gcj and use that, but that's probably a bit trickier. > Eric > >> >> >>> >>> -- >>> Andrew :-) >>> >>> Support Free Java! >>> Contribute to GNU Classpath and the OpenJDK >>> http://www.gnu.org/software/classpath >>> http://openjdk.java.net >>> >>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 >>> >> >> >> >> > > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ekrichardson at gmail.com Tue Dec 30 23:48:42 2008 From: ekrichardson at gmail.com (Eric Richardson) Date: Tue, 30 Dec 2008 23:48:42 -0800 Subject: Power PC Build In-Reply-To: <17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> <860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com> <17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com> Message-ID: <860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com> Andrew, On Mon, Dec 29, 2008 at 11:30 PM, Andrew John Hughes < gnu_andrew at member.fsf.org> wrote: > 2008/12/30 Eric Richardson : > > Michael, > > > > On Mon, Dec 29, 2008 at 3:57 PM, Michael Franz > wrote: > >> > >> Andrew, > >> > >> On Sun, Dec 28, 2008 at 6:26 PM, Andrew John Hughes > >> wrote: > >> > >>> > >>> IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a > >>> --with-project=bsd option for supporting using the BSD tree in place > >>> of the main JDK7 tree. It just needs testing. I think supporting the > >>> use of BSD as an alternate icedTea build is the better solution long > >>> term. All it really needs is someone will to try building on Mac > >>> OS/BSD and to maintain it long-term by supplying us with patches. > >>> No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK) but > >>> we're certainly open to more contributors and to supporting more > >>> platforms. I'd much prefer this to forking zero support. There are > >>> also other features such as the web plugin, web start support, etc. in > >>> IcedTea that may be useful for BSD and Mac OS X users. > >> > >> I made a quick attempt at building icedtea7 on OS X. The autogen.sh > fails > >> with the following: > >> onfigure.ac:4: installing `./config.guess' > >> configure.ac:4: installing `./config.sub' > >> configure.ac:2: installing `./install-sh' > >> Makefile.am:1304: variable `PULSEAUDIO_SOURCES' is defined but no > program > >> or > >> Makefile.am:1304: library has `PULSEAUDIO' as canonic name (possible > typo) > >> Makefile.am:1227: variable `JTREG_SOURCES' is defined but no program or > >> Makefile.am:1227: library has `JTREG' as canonic name (possible typo) > >> > >> Also, I was not able to find IcedTea7 specific instructions. Are there > >> any? > >> > >> Michael > >> > > > > I got this same error but tried configure anyway > > > > ./configure --with-openjdk-home=/Library/Java/Home --enable-zero=yes > > --with-project=bsd --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar > > > --with-alt-jar=/System/LibrarFrameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar > > > > checking for libgcj-4.3.*.jar... > > configure: error: "A LIBGCJ jar was not found." > > > > Either use an OpenJDK/IcedTea build by adding --with-openjdk or > specify --with-libgcj-jar to point to rt.jar. > As I said in my previous email though, the libgcj build will not work > with a non-Classpath/GCJ build environment. > (--with-libgcj-jar is gone from IcedTea6, it will go from 7 when we next > merge). This suggestion was very helpful. The problem using the JDK 5 on the Mac is that instead of having an rt.jar they have classes.jar and ui.jar so you can't use the --with-openjdk-home so you must use --with-libgcj-jar=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar but unfortunately I had a typo in the path. I have been reading your posts but much is new and I certainly don't understand it all. Removing the --with-libgcj-jar cuts off the path to what I am attempting to do. (icedtea6 no longer works since I updated) If you can use any java 5 complier to create IcedTea JDK, the resultant can be used after that. If it is possible to keep IcedTea like IcePick "which allows the OpenJDK language tools (javac, javadoc, javah, javap, apt) to be built separately using any 1.5 compliant Java compiler..." that would be great. Unless there is an alternate way to point to the runtime jar. > > > I thought maybe I could clear this problem by trying to compile > gcj34(from > > MacPorts) using gcc42? The gcc 4.0.1 wouldn't do it and I saw a post > > on http://trac.macports.org/ticket/9730 that said > > > > How would an ancient gcj help? You want 4.3 > > > wontfix the gcj34 port because pdftk compiles just fine on Intel and > PowerPC > > Macs using gcc42, which has been the default for pdftk since r25014. > > > > Would this help me out for Icetea7 or some other path or is this a dead > end? > > > > What tools (gcc, gcj etc) and versions would be good to start with? > > > > Building GNU Classpath + CACAO might be the easiest option, then use > that to build IcedTea. > Or build gcc 4.3 with gcj and use that, but that's probably a bit trickier. I built gcc 4.2 as this was available via MacPorts. Icedtea still looks promising but now I'm stuck on the ALSA part of configure. checking for ALSA... no configure: error: Could not find alsa - Try installing alsa-lib-devel. The only thing I could find remotely related was Libao2. Note: the problem I had before fwas because I was missing pkg.m4 which in turn got fixed when I installed xorg-libX11. ./configure: line 11562: syntax error near unexpected token `XPROTO,' ./configure: line 11562: `PKG_CHECK_MODULES(XPROTO, xproto,XPROTO_FOUND=yes,XPROTO_FOUND=no) Eric -- > Andrew :-) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081230/fc1f6e8f/attachment.html From gnu_andrew at member.fsf.org Wed Dec 31 07:46:38 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 31 Dec 2008 15:46:38 +0000 Subject: Power PC Build In-Reply-To: <860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> <860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com> <17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com> <860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com> Message-ID: <17c6771e0812310746i413e95bbl99813bf99b989496@mail.gmail.com> 2008/12/31 Eric Richardson : > Andrew, > > On Mon, Dec 29, 2008 at 11:30 PM, Andrew John Hughes > wrote: >> >> 2008/12/30 Eric Richardson : >> > Michael, >> > >> > On Mon, Dec 29, 2008 at 3:57 PM, Michael Franz >> > wrote: >> >> >> >> Andrew, >> >> >> >> On Sun, Dec 28, 2008 at 6:26 PM, Andrew John Hughes >> >> wrote: >> >> >> >>> >> >>> IcedTea[7] (http://icedtea.classpath.org/hg/icedtea) already has a >> >>> --with-project=bsd option for supporting using the BSD tree in place >> >>> of the main JDK7 tree. It just needs testing. I think supporting the >> >>> use of BSD as an alternate icedTea build is the better solution long >> >>> term. All it really needs is someone will to try building on Mac >> >>> OS/BSD and to maintain it long-term by supplying us with patches. >> >>> No-one currently on the IcedTea team uses BSD or Mac OS X (AFAIK) but >> >>> we're certainly open to more contributors and to supporting more >> >>> platforms. I'd much prefer this to forking zero support. There are >> >>> also other features such as the web plugin, web start support, etc. in >> >>> IcedTea that may be useful for BSD and Mac OS X users. >> >> >> >> I made a quick attempt at building icedtea7 on OS X. The autogen.sh >> >> fails >> >> with the following: >> >> onfigure.ac:4: installing `./config.guess' >> >> configure.ac:4: installing `./config.sub' >> >> configure.ac:2: installing `./install-sh' >> >> Makefile.am:1304: variable `PULSEAUDIO_SOURCES' is defined but no >> >> program >> >> or >> >> Makefile.am:1304: library has `PULSEAUDIO' as canonic name (possible >> >> typo) >> >> Makefile.am:1227: variable `JTREG_SOURCES' is defined but no program or >> >> Makefile.am:1227: library has `JTREG' as canonic name (possible typo) >> >> >> >> Also, I was not able to find IcedTea7 specific instructions. Are there >> >> any? >> >> >> >> Michael >> >> >> > >> > I got this same error but tried configure anyway >> > >> > ./configure --with-openjdk-home=/Library/Java/Home --enable-zero=yes >> > --with-project=bsd --with-ecj-jar=/opt/local/share/java/eclipse-ecj.jar >> > >> > --with-alt-jar=/System/LibrarFrameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar >> > >> > checking for libgcj-4.3.*.jar... >> > configure: error: "A LIBGCJ jar was not found." >> > >> >> Either use an OpenJDK/IcedTea build by adding --with-openjdk or >> specify --with-libgcj-jar to point to rt.jar. >> As I said in my previous email though, the libgcj build will not work >> with a non-Classpath/GCJ build environment. >> (--with-libgcj-jar is gone from IcedTea6, it will go from 7 when we next >> merge). > > This suggestion was very helpful. The problem using the JDK 5 on the Mac is > that instead of having an rt.jar they have classes.jar and ui.jar so you > can't use the --with-openjdk-home so you must use > --with-libgcj-jar=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar > but unfortunately I had a typo in the path. I have been reading your posts > but much is new and I certainly don't understand it all. > --with-openjdk-home wouldn't be an option anyway, it's --with-gcj-home. There are basically three possible setups: * default build: does a bootstrap build (build with gcj+ecj first, then the built IcedTea), --with-gcj-home can be used to point to the JDK tree. * openjdk build: --with-openjdk turns this on, --with-openjdk-home points to the JDK tree. The build JDK is expected to be a copy of raw OpenJDK. Not sure how well tested this is anymore. * icedtea build --with-icedtea turns this on, --with-icedtea-home points to the JDK tree. The build JDK is expected to be an earlier IcedTea. It essentially does the second stage of the default build, and fails even with the oldest versions of IcedTea (those based on 7) as it expects some plugin classes to be in the existing IcedTea build. --with-libgcj-jar was dropped because it doesn't really fit in coherently. It was only being used by the default build, but yet there was no equivalent for the openjdk or icedtea builds. It doesn't get around the need for a correct JDK tree as libjvm.so will be expected to be present in jre/lib/${arch}/(client|server). IcedTea seems to have adopted a hybrid approach of assuming and not assuming a JDK tree for the GCJ build and it simplifies things if we settle on a single approach. The JDK tree structure has become a defacto standard and is relied upon by quite a few Java applications, especially Apache ones. I'm surprised that the JDK you have doesn't follow this. We had a lot of problems with GNU Classpath when running applications that expected this structure of a tools.jar with the compiler, an rt.jar with the class library, etc. to the point that gcj-java-compat was created to provide a JDK-like tree for GCJ installs. In turn, the IcedTea build expects this to be present as it is on current versions of Fedora, Debian, Ubuntu, etc. with the correct packages installed. It's actually easier to create such a tree than pass in numerous options to specify every little file. Just create a tree with a jre/lib/rt.jar pointing to your class library and a jre/lib/${arch}/(client|server)/libjvm.so pointing to your libjvm.so e.g. $ find /usr/lib/gcj-jdk-4.3 /usr/lib/gcj-jdk-4.3 /usr/lib/gcj-jdk-4.3/bin /usr/lib/gcj-jdk-4.3/bin/jar /usr/lib/gcj-jdk-4.3/bin/java /usr/lib/gcj-jdk-4.3/bin/rmic /usr/lib/gcj-jdk-4.3/bin/keytool /usr/lib/gcj-jdk-4.3/bin/javac /usr/lib/gcj-jdk-4.3/bin/javah /usr/lib/gcj-jdk-4.3/bin/javap /usr/lib/gcj-jdk-4.3/bin/appletviewer /usr/lib/gcj-jdk-4.3/bin/jarsigner /usr/lib/gcj-jdk-4.3/bin/javadoc /usr/lib/gcj-jdk-4.3/bin/rmiregistry /usr/lib/gcj-jdk-4.3/jre /usr/lib/gcj-jdk-4.3/jre/bin /usr/lib/gcj-jdk-4.3/jre/bin/java /usr/lib/gcj-jdk-4.3/jre/bin/keytool /usr/lib/gcj-jdk-4.3/jre/bin/rmiregistry /usr/lib/gcj-jdk-4.3/jre/lib /usr/lib/gcj-jdk-4.3/jre/lib/amd64 /usr/lib/gcj-jdk-4.3/jre/lib/amd64/client /usr/lib/gcj-jdk-4.3/jre/lib/amd64/client/libjvm.so /usr/lib/gcj-jdk-4.3/jre/lib/amd64/libjawt.so /usr/lib/gcj-jdk-4.3/jre/lib/amd64/server /usr/lib/gcj-jdk-4.3/jre/lib/amd64/server/libjvm.so /usr/lib/gcj-jdk-4.3/jre/lib/rt.jar /usr/lib/gcj-jdk-4.3/lib /usr/lib/gcj-jdk-4.3/lib/tools.jar /usr/lib/gcj-jdk-4.3/include The above is now created by the Gentoo gcj-jdk ebuild after a process of trial and error finding what was expected by different Java apps, etc. Note that include is a symlink to gcj's include directory with jni.h. > Removing the --with-libgcj-jar cuts off the path to what I am attempting to > do. (icedtea6 no longer works since I updated) If you can use any java 5 > complier to create IcedTea JDK, the resultant can be used after that. If it > is possible to keep IcedTea like IcePick "which allows the OpenJDK language > tools (javac, javadoc, javah, javap, apt) to be built separately using any > 1.5 compliant Java compiler..." that would be great. Unless there is an > alternate way to point to the runtime jar. > -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From mvfranz at gmail.com Wed Dec 31 13:06:38 2008 From: mvfranz at gmail.com (Michael Franz) Date: Wed, 31 Dec 2008 16:06:38 -0500 Subject: Power PC Build In-Reply-To: <860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com> References: <860cb0120812272312j1d310307mcf9864247003567e@mail.gmail.com> <20081228182936.GA7488@misty.eyesbeyond.com> <17c6771e0812281526u3c4b84fes4599a7922ac20025@mail.gmail.com> <860cb0120812292044j45056968oe34be61ed5ddd43d@mail.gmail.com> <17c6771e0812292330o4afa6702j8a04a115ae6276be@mail.gmail.com> <860cb0120812302348t6620a544k22292f0b09cbbdc@mail.gmail.com> Message-ID: Eric, On Wed, Dec 31, 2008 at 2:48 AM, Eric Richardson wrote: > Andrew, > I built gcc 4.2 as this was available via MacPorts. > > Icedtea still looks promising but now I'm stuck on the ALSA part of > configure. > > checking for ALSA... no > configure: error: Could not find alsa - Try installing alsa-lib-devel. > > The only thing I could find remotely related was Libao2. > To work around this I change configure.ac to change the ALSA to a warning instead of an error and then run autogen.sh --- configure.ac.orig 2008-12-31 16:03:56.000000000 -0500 +++ configure.ac 2008-12-31 16:04:17.000000000 -0500 @@ -436,7 +436,7 @@ PKG_CHECK_MODULES(ALSA, alsa,[ALSA_FOUND=yes],[ALSA_FOUND=no]) if test "x${ALSA_FOUND}" = xno then - AC_MSG_ERROR([Could not find alsa - \ + AC_MSG_WARN([Could not find alsa - \ Try installing alsa-lib-devel.]) fi AC_SUBST(ALSA_CFLAGS) I figure I will deal with the ALSA error later if I ever get to them. Michael > > Note: the problem I had before fwas because I was missing pkg.m4 which in > turn got fixed when I installed xorg-libX11. > > ./configure: line 11562: syntax error near unexpected token `XPROTO,' > ./configure: line 11562: `PKG_CHECK_MODULES(XPROTO, > xproto,XPROTO_FOUND=yes,XPROTO_FOUND=no) > > Eric > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/bsd-port-dev/attachments/20081231/e778f367/attachment.html From Xiaobin.Lu at Sun.COM Wed Dec 31 20:32:26 2008 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Wed, 31 Dec 2008 20:32:26 -0800 Subject: Patch to build 64 bit VM In-Reply-To: <20081229164706.GA52523@misty.eyesbeyond.com> References: <4949DC28.6020703@Sun.COM> <20081222140953.GC96610@misty.eyesbeyond.com> <494FE536.1040102@Sun.COM> <20081226072429.GA69479@misty.eyesbeyond.com> <49548922.80703@Sun.COM> <20081226172736.GA42840@misty.eyesbeyond.com> <20081228082926.GA77650@misty.eyesbeyond.com> <20081228205541.GA11757@misty.eyesbeyond.com> <4957F135.3040300@Sun.COM> <20081229164706.GA52523@misty.eyesbeyond.com> Message-ID: <495C475A.1030405@Sun.COM> Greg Lewis wrote: > G'day Xiaobin, > > On Sun, Dec 28, 2008 at 01:35:49PM -0800, Xiaobin Lu wrote: > >> I tested your patch and it worked fine on 32 & 64 bit build. However, we >> still need the patch for src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp. >> The patch looks like the following: >> >> diff -r de4c58dbee8f src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp >> --- a/src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp Wed Nov 26 >> 05:05:13 2008 -0800 >> +++ b/src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp Wed Dec 17 >> 21:06:49 2008 -0800 >> @@ -32,9 +32,9 @@ >> >> #if defined(AMD64) >> # if defined(__APPLE__) >> -# define bswap16(x) OSSwapInt16(x) >> -# define bswap32(x) OSSwapInt32(x) >> -# define bswap64(x) OSSwapInt64(x) >> +# define bswap_16(x) OSSwapInt16(x) >> +# define bswap_32(x) OSSwapInt32(x) >> +# define bswap_64(x) OSSwapInt64(x) >> # elif defined(__OpenBSD__) >> # define bswap_16(x) swap16(x) >> # define bswap_32(x) swap32(x) >> >> You may want to check in the above as well. By the way, I've already >> integrated my fix to solve the intptr_t and int32_t into hotspot-rt >> repository (http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot). It will >> probably take another week for the fix to show up in the hotspot main >> repository. >> > > Yep, we do need that too. Can you please check it in? I'll check my > change in too and we should have a working 64 bit build. It sounds like > the 32 bit build will be fixed once your other change bubbles up into > the main tree and we do a merge. > > BTW, how are you passing in -m64 to the build on Mac OS X? > Greg, I tried to pass in LP64=1 to build 64 bit VM on Mac OS. This is same as other platforms. It looks like you have checked in the fix to os_bsd_x86.cpp so I don't believe I have to do anything more. Regards, Happy new year. -Xiaobin > >> Greg Lewis wrote: >> >>> On Sun, Dec 28, 2008 at 12:29:26AM -0800, Greg Lewis wrote: >>> >>> >>>> On Fri, Dec 26, 2008 at 09:27:36AM -0800, Greg Lewis wrote: >>>> >>>> >>>>> On Thu, Dec 25, 2008 at 11:34:58PM -0800, Xiaobin Lu wrote: >>>>> >>>>> >>>>>> So with my openjdk id, I can commit the changes without extra permission? >>>>>> >>>>>> >>>>> I think I should have looked harder at the change first, sorry. I tried >>>>> compiling with that change in and it broke the i386 build :(. I'm looking >>>>> at things side by side with the current Linux code to try and get the >>>>> braces and #ifdef's right, but I have to say this part of the code is >>>>> becoming quite confusing with the proliferation of preprocessor >>>>> conditionals. >>>>> >>>>> I hope to have something later today that you can test on Mac OS X. >>>>> >>>>> >>>> Instead I shovelled snow/ice for a couple of days so we could get out of >>>> our house to the main roads :). >>>> >>>> Anyway, attached is a patch. Its not yet compile tested, I've got the >>>> compile started however and will check in the morning. Please give it >>>> a try on Mac OS X. Basically it looks like the special handling for >>>> 64 bit Mac OS X was half merged into the x86 handling. >>>> >>>> >>> Oops, as Kurt pointed out I forgot to attach the patch... Trying again. >>> >>> >>> >>>>>> Greg Lewis wrote: >>>>>> >>>>>> >>>>>>> G'day Xiaobin, >>>>>>> >>>>>>> On Mon, Dec 22, 2008 at 11:06:30AM -0800, Xiaobin Lu wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I am attaching the patch to make the VM build pass on Mac OS 64 bit. >>>>>>>> Here is some explanation on the change: >>>>>>>> >>>>>>>> bytes_bsd_x86.inline.cpp: >>>>>>>> >>>>>>>> Change bswap16(x) to bswap_16(x) and the similar, I believe there was a >>>>>>>> typo for this. When some ported this to Apple platform, they missed a >>>>>>>> underscore. >>>>>>>> >>>>>>>> os_bsd_x86.cpp >>>>>>>> >>>>>>>> There was a "}" missing for 64 bit build. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Thats a lot clearer when I use diff -b :). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Other changes to make the build pass will be covered by my fix to >>>>>>>> 6787106 which I am going to put back to open JDK 7 tree soon. >>>>>>>> >>>>>>>> Please help me review the patch and feel free to let me know if there >>>>>>>> was anything wrong. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Looks good to me -- I say go ahead and commit it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Greg Lewis wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> G'day Xiaobin, >>>>>>>>> >>>>>>>>> On Wed, Dec 17, 2008 at 09:14:16PM -0800, Xiaobin Lu wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I am attaching the patch for building 64 bit VM. They are BSD specific >>>>>>>>>> files. Would someone review it and help me check it in? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Sure. Can you comment a little on the changes to >>>>>>>>> src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp? It seems like the diff is >>>>>>>>> bigger than the changes if that makes sense (i.e. there are some whitespace >>>>>>>>> changes due to control flow changes which are hiding those). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> -- >>>>> Greg Lewis Email : glewis at eyesbeyond.com >>>>> Eyes Beyond Web : http://www.eyesbeyond.com >>>>> Information Technology FreeBSD : glewis at FreeBSD.org >>>>> >>>>> >>>> -- >>>> Greg Lewis Email : glewis at eyesbeyond.com >>>> Eyes Beyond Web : http://www.eyesbeyond.com >>>> Information Technology FreeBSD : glewis at FreeBSD.org >>>> >>>> >>> >>> > >