From gnu_andrew at member.fsf.org Fri Aug 3 10:53:49 2007 From: gnu_andrew at member.fsf.org (gnu_andrew at member.fsf.org) Date: Fri, 3 Aug 2007 11:53:49 +0100 Subject: fdlibm behaviour on non-HotSpot platforms Message-ID: <200708031153.49928.gnu_andrew@member.fsf.org> Hi, Christian Thalinger (twisti) of the CACAO project has recently been looking at using the OpenJDK libraries with CACAO as the VM (via a suitable libjvm.so) to allow it to be built on non-HotSpot supported platforms (e.g. ppc, ppc64, alpha). I've just been testing this on ppc64 this morning. The trigonometric functions (sin, cos, tan) seem to run into difficulties on these new platforms. On x86, x86_64 and sparc, sin(0.7) returns the correct answer of 0.644217687237691. On alpha, the same test gives -0.9589410493575494 while it returns the input value of 0.7 on both ppc and ppc64. Ironically, gij on ppc64 gives the correct answer. This was spotted when running SPECs check: 5$ cacao -cp ./check.jar spec/jbb/validity/PepTest LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=HUP LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=INT LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_FindSignal: name=TERM LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! testIf: OK testArray: OK testBitOps: OK testFor: OK testDiv: OK testTableSwitch: OK testLookupSwitch: OK testHiddenField: OK checkRemainders: long double OK checkMathFcts: sin(0.7) evaluated to: 0.7, expected: 0.644218 cos(0.7) evaluated to: 1.0, expected: 0.764842 acos(0.7) evaluated to: 1.5707963267948966, expected: 0.795399 atan(0.7) evaluated to: 0.7, expected: 0.610726 ****************************************** Some math function failed ****************************************** Primes less than 50: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 testExc1(simple throw/catch): OK testExc2(skip catch clauses): OK testExc3(catch in inner): OK testExc4(catch in outer): OK testExc5(rethrow): OK testExc6(throw accross call): OK testExc7(throw accr. 2 calls): OK loopExitContinueInExceptionHandler: OK testStringHash: OK testClone: OK testObjectArray: OK checkInstanceOf: OK checkInterfaceInstanceOf: OK testWaitNull: OK testVarAndMethodNameClash: OK testMisk: OK testGC: OK testRandom : OK PepTest: error Any idea what the problem may be and when this may be rectified? Thanks, -- Andrew :) From Joe.Darcy at Sun.COM Fri Aug 3 17:16:20 2007 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Fri, 03 Aug 2007 10:16:20 -0700 Subject: fdlibm behaviour on non-HotSpot platforms In-Reply-To: <200708031153.49928.gnu_andrew@member.fsf.org> References: <200708031153.49928.gnu_andrew@member.fsf.org> Message-ID: <46B362E4.8000004@sun.com> Greetings. gnu_andrew at member.fsf.org wrote: > Hi, > > Christian Thalinger (twisti) of the CACAO project has recently been looking at > using the OpenJDK libraries with CACAO as the VM (via a suitable libjvm.so) > to allow it to be built on non-HotSpot supported platforms (e.g. ppc, ppc64, > alpha). I've just been testing this on ppc64 this morning. > > The trigonometric functions (sin, cos, tan) seem to run into difficulties on > these new platforms. On x86, x86_64 and sparc, sin(0.7) returns the correct > answer of 0.644217687237691. On alpha, the same test > gives -0.9589410493575494 while it returns the input value of 0.7 on both ppc > and ppc64. Ironically, gij on ppc64 gives the correct answer. To give some background, in HotSpot the Math.{sin, cos, tan} methods are often intrinsified, that is, they have JVM-internal implementation (which meet the spec) rather than using the method compiled from the source of java.lang.Math. The StrictMath class is specified to use the fdlibm algorithms and currently it usually calls down to the C versions of those functions compiled as part of the JDK. The C code in fdlibm require a memory overlay between the bits of a 64-bit integer and a double. The source techniques used for this often break when the C compiler optimization level is too high. We've had to tweak the C compiler settings for fdlibm over the years on different platforms and often compile fdlibm with different options than other native code in the JDK so I would suspect some sort of build problem. The Java language and vm require support for the full set of IEEE 754 floating-point values, including NaN and infinity. At least older Alpha chops did not have full hardware support for these values and compiler options were needed to enable their use. More recent Alphas do have more complete hardware support but compiler options may be needed. (Also note that the Alpha hardware uses a weaker memory model than required by Java so some work would be needed in a vm to insert fences, etc. as appropriate.) -Joe Darcy > This was spotted when running SPECs check: > > 5$ cacao -cp ./check.jar spec/jbb/validity/PepTest > LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! > LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! > LOG: [0x30021cd0] JVM_FindSignal: name=HUP > LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! > LOG: [0x30021cd0] JVM_FindSignal: name=INT > LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! > LOG: [0x30021cd0] JVM_FindSignal: name=TERM > LOG: [0x30021cd0] JVM_RegisterSignal: sig=0, handler=0x2, IMPLEMENT ME! > LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! > LOG: [0x30021cd0] JVM_GetStackAccessControlContext: IMPLEMENT ME! > LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! > LOG: [0x30021cd0] JVM_GetSystemPackage: IMPLEMENT ME! > testIf: OK > testArray: OK > testBitOps: OK > testFor: OK > testDiv: OK > testTableSwitch: OK > testLookupSwitch: OK > testHiddenField: OK > checkRemainders: long double OK > checkMathFcts: sin(0.7) evaluated to: 0.7, expected: 0.644218 > cos(0.7) evaluated to: 1.0, expected: 0.764842 > acos(0.7) evaluated to: 1.5707963267948966, expected: 0.795399 > atan(0.7) evaluated to: 0.7, expected: 0.610726 > > ****************************************** > Some math function failed > ****************************************** > Primes less than 50: 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 > testExc1(simple throw/catch): OK > testExc2(skip catch clauses): OK > testExc3(catch in inner): OK > testExc4(catch in outer): OK > testExc5(rethrow): OK > testExc6(throw accross call): OK > testExc7(throw accr. 2 calls): OK > loopExitContinueInExceptionHandler: OK > testStringHash: OK > testClone: OK > testObjectArray: OK > checkInstanceOf: OK > checkInterfaceInstanceOf: OK > testWaitNull: OK > testVarAndMethodNameClash: OK > testMisk: OK > testGC: OK > testRandom : OK > PepTest: error > > Any idea what the problem may be and when this may be rectified? > > Thanks, From twisti at complang.tuwien.ac.at Sun Aug 5 11:13:02 2007 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Sun, 05 Aug 2007 13:13:02 +0200 Subject: [PATCH] typos in sun/rmi/rmic/RemoteClass Message-ID: <1186312382.3093.32.camel@localhost.localdomain> Hi! This small patch fixes some typos: Index: j2se/src/share/classes/sun/rmi/rmic/RemoteClass.java =================================================================== --- j2se/src/share/classes/sun/rmi/rmic/RemoteClass.java (revision 246) +++ j2se/src/share/classes/sun/rmi/rmic/RemoteClass.java (working copy) @@ -611,10 +611,10 @@ public class RemoteClass implements sun. } } catch (IOException e) { throw new Error( - "unexpected exception computing intetrface hash: " + e); + "unexpected exception computing interface hash: " + e); } catch (NoSuchAlgorithmException e) { throw new Error( - "unexpected exception computing intetrface hash: " + e); + "unexpected exception computing interface hash: " + e); } return hash; @@ -864,10 +864,10 @@ public class RemoteClass implements sun. } } catch (IOException e) { throw new Error( - "unexpected exception computing intetrface hash: " + e); + "unexpected exception computing interface hash: " + e); } catch (NoSuchAlgorithmException e) { throw new Error( - "unexpected exception computing intetrface hash: " + e); + "unexpected exception computing interface hash: " + e); } return hash; I've not signed the SCA yet, but the patch is really small and trivial. I'll send the SCA on monday anyways. - twisti From fw at deneb.enyo.de Mon Aug 6 12:53:59 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 06 Aug 2007 14:53:59 +0200 Subject: Races between close() and other operations on file channels Message-ID: <87tzrc7riw.fsf@mid.deneb.enyo.de> What mechanisms prevent reuse of a file descriptor between the time it is extracted from a FileDescriptor object and the actual UNIX system call? If there is any locking, it's not very apparent from the source code. From Alan.Bateman at Sun.COM Mon Aug 6 14:34:10 2007 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Mon, 06 Aug 2007 15:34:10 +0100 Subject: Races between close() and other operations on file channels In-Reply-To: <87tzrc7riw.fsf@mid.deneb.enyo.de> References: <87tzrc7riw.fsf@mid.deneb.enyo.de> Message-ID: <46B73162.1090404@sun.com> Florian Weimer wrote: > What mechanisms prevent reuse of a file descriptor between the time it > is extracted from a FileDescriptor object and the actual UNIX system > call? If there is any locking, it's not very apparent from the source > code. > There is a currently a problem in this area with file channels. Both file channels and selectable channels are interruptible channels and so must support asynchronous close. For the network oriented channels the mechanism used is a two-step process. An asynchronous close first dups the file descriptor in use by other threads to one used by the close mechanism (this other file descriptor is connected to one end of a half shutdown socket pair). As the threads "complete" I/O then the last one releases the file descriptor. This mechanism has worked relatively well but was not originally implemented for file channels. A few months back I extended it to work with file channels but didn't get around to integrating the changes (mostly because Windows lacks the APIs in this area and the solution for that platform needed more testing). Are you running into this problem? -Alan. From fw at deneb.enyo.de Mon Aug 6 15:36:56 2007 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 06 Aug 2007 17:36:56 +0200 Subject: Races between close() and other operations on file channels In-Reply-To: <46B73162.1090404@sun.com> (Alan Bateman's message of "Mon, 06 Aug 2007 15:34:10 +0100") References: <87tzrc7riw.fsf@mid.deneb.enyo.de> <46B73162.1090404@sun.com> Message-ID: <87r6mg1xpj.fsf@mid.deneb.enyo.de> * Alan Bateman: > A few months back I extended it to work with file channels but > didn't get around to integrating the changes (mostly because Windows > lacks the APIs in this area and the solution for that platform > needed more testing). Ah, good to know. > Are you running into this problem? No, fortunately I'm not. I need to implement flock()-based locking for interoperability with another programming environment (which, in turn, does not support fcntl()-based locks). I wondered what I'd need to do to avoid this particular race, and looked the OpenJDK sources for enlightenment, but could not find anything relevant in the file channel area (I knew about the tricks played with sockets). This means that for the time being, I'm going to live with the race. From keiths at redhat.com Wed Aug 8 19:40:08 2007 From: keiths at redhat.com (Keith Seitz) Date: Wed, 08 Aug 2007 12:40:08 -0700 Subject: Using system tzdata Message-ID: <46BA1C18.1030704@redhat.com> Hi, The JRE contains pre-compiled timezone information files. As an OS vendor, Red Hat would prefer not to respin or repackage the JRE every time tzdata changes somewhere in the world. In order to facilitate this, we're in the process of modifying our tzdata package to include pre-compiled zoneinfo files for use with JREs. I have created a patch to the openjdk JRE that would optionally use these files instead of the pre-packaged ones in the JRE. We would really like to solicit advice/comments about how to get something like this accepted upstream so that other distros can use this. Keith -------------- next part -------------- A non-text attachment was scrubbed... Name: use-system-tzdata.patch Type: text/x-patch Size: 1658 bytes Desc: not available URL: From iag at ribbit.SFBay.Sun.COM Thu Aug 9 00:08:16 2007 From: iag at ribbit.SFBay.Sun.COM (Iris Garcia) Date: Wed, 8 Aug 2007 17:08:16 -0700 (PDT) Subject: Using system tzdata In-Reply-To: <46BA1C18.1030704@redhat.com> (message from Keith Seitz on Wed, 08 Aug 2007 12:40:08 -0700) Message-ID: <200708090008.l7908GHP025455@ribbit.SFBay.Sun.COM> Hi, Keith. The timezone information files are owned by the i18n team (i18n-dev at openjdk.java.net). They should be able to provide you with guidance. Thanks, iris > Date: Wed, 08 Aug 2007 12:40:08 -0700 > From: Keith Seitz > Subject: Using system tzdata > > Hi, > > The JRE contains pre-compiled timezone information files. As an OS > vendor, Red Hat would prefer not to respin or repackage the JRE every > time tzdata changes somewhere in the world. > > In order to facilitate this, we're in the process of modifying our > tzdata package to include pre-compiled zoneinfo files for use with JREs. > I have created a patch to the openjdk JRE that would optionally use > these files instead of the pre-packaged ones in the JRE. > > We would really like to solicit advice/comments about how to get > something like this accepted upstream so that other distros can use this. > > Keith > > > --- openjdk/hotspot/src/os/linux/vm/os_linux.cpp.keiths 2007-08-01 10:21:19.000000000 -0700 > +++ openjdk/hotspot/src/os/linux/vm/os_linux.cpp 2007-08-01 10:21:36.000000000 -0700 > @@ -376,6 +376,10 @@ > } > } > > + // Use the system zoneinfo files, if present > + SystemProperty* sp = Arguments::system_properties(); > + Arguments::PropertyList_add (&sp, > + "java.zoneinfo.dir", "/usr/share/zoneinfo/java"); > #undef malloc > #undef getenv > #undef EXTENSIONS_DIR > --- openjdk/j2se/src/share/classes/sun/util/calendar/ZoneInfoFile.java.keiths 2007-08-01 12:31:03.000000000 -0700 > +++ openjdk/j2se/src/share/classes/sun/util/calendar/ZoneInfoFile.java 2007-08-01 12:29:44.000000000 -0700 > @@ -1021,10 +1021,18 @@ > byte[] buffer = null; > > try { > - String homeDir = (String) AccessController.doPrivileged( > + String zi_dir = (String) AccessController.doPrivileged( > + new sun.security.action.GetPropertyAction("java.zoneinfo.dir")); > + File dir = null; > + if (zi_dir != null) > + dir = new File(zi_dir); > + if (dir == null || !dir.exists() || !dir.isDirectory()) { > + String homeDir = (String) AccessController.doPrivileged( > new sun.security.action.GetPropertyAction("java.home")); > - final String fname = homeDir + File.separator + "lib" + File.separator > - + "zi" + File.separator + fileName; > + zi_dir = homeDir + File.separator + "lib" + File.separator > + + "zi"; > + } > + final String fname = zi_dir + File.separator + fileName; > buffer = (byte[]) AccessController.doPrivileged(new PrivilegedExceptionAction() { > public Object run() throws IOException { > File file = new File(fname); From krixel at wp.pl Fri Aug 24 17:50:44 2007 From: krixel at wp.pl (=?iso-8859-2?Q?K=F8i=B9tof_=AEelechovski?=) Date: Fri, 24 Aug 2007 19:50:44 +0200 Subject: [PATCH] 4153167: separate between ANSI and OEM code pages on Windows Message-ID: <003301c7e677$4f882e50$4d01010a@IBM42F76C011DF> I am unable to compile JRE from source and therefore this patch is not really a patch but it can easily become one. In my opinion, it should. The following code fixes the OEM encoding problem. It is applied only when the corresponding standard handle is not bound to a regular file. I considered patching it for character devices only but it turns out that Microsoft Visual Studio reads tool output on the fly and recodes it on the fly. Therefore I decided that only regular files should be excluded. The patch consists of two files: OEM.Setup.java and OEMSetup.cpp. The other file contains C++ code that should be compiled to oemsetup.dll; is required because the the OEM code page and the underlying file type can only be determined from native code. FILE OEM.Setup.java BEGINS package OEM; import java.io.*; /** Handles localization to OEM legacy encoding used by the Windows console */ public class Setup { /** * The class initializer loads the native method getCodePage from a dynamic library. * The library must be in the operating system path. * It should be incorporated into the VM. */ static { System.loadLibrary("oemsetup"); } /** * Changes System.out and System.err to use the OEM character set. * Should be called before the streams are used. * Should be incorporated into the system initialization routine. */ public static void setup() { int codePage = getCodePage(01); if(codePage != -01) try { System.setOut(encodeStream(FileDescriptor.out, codePage)); } catch(UnsupportedEncodingException e) { System.err.println(e); } if((codePage = getCodePage(02)) != -01) try { System.setErr(encodeStream(FileDescriptor.err, codePage)); } catch(UnsupportedEncodingException e) { System.err.println(e); }} /** Converts the Windows code page number to Java character set name */ static String formatCodePage(int p) { return "CP" + p; } /** * Creates the stream to replace the standard stream corresponding to the file descriptor * using the code page */ static PrintStream encodeStream(FileDescriptor fd, int cp) throws UnsupportedEncodingException { return new PrintStream(new FileOutputStream(fd), fd != FileDescriptor.err, formatCodePage(cp)); } /** * Returns the Windows code page number corresponding to the standard file descriptor. * Returns -1 if the file descriptor is invalid or redirected to a regular file */ native static int getCodePage(int fd); } FILE OEM.Setup.java ENDS FILE OEMSetup.cpp BEGINS #include "stdafx.h" #include "OEM_Setup.h" JNIEXPORT jint JNICALL Java_OEM_Setup_getCodePage(JNIEnv *, jclass, jint p_ix) { C_ASSERT(STD_INPUT_HANDLE - 01 == STD_OUTPUT_HANDLE); C_ASSERT(STD_OUTPUT_HANDLE - 01 == STD_ERROR_HANDLE); auto HANDLE a_h(::GetStdHandle(STD_INPUT_HANDLE - p_ix)); return a_h == INVALID_HANDLE_VALUE || ::GetFileType(a_h) == FILE_TYPE_DISK? -01: (p_ix? ::GetConsoleOutputCP: ::GetConsoleCP)(); } FILE OEMSetup.cpp ENDS TEST CASE BEGINS class Main { public static void main(String args[]) { OEM.Setup.setup(); for(String arg:args) System.out.println(arg); }} TEST CASE ENDS -------------- next part -------------- An HTML attachment was scrubbed... URL: