August 2007 - core-libs-dev

fdlibm behaviour on non-HotSpot platforms
by gnu_andrew＠member.fsf.org 04 Oct '07

04 Oct '07

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 :)

3 2

[PATCH] 4153167: separate between ANSI and OEM code pages on Windows
by Křištof Želechovski 24 Aug '07

24 Aug '07

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

1 0

Using system tzdata
by Keith Seitz 09 Aug '07

09 Aug '07

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

2 1

Races between close() and other operations on file channels
by Florian Weimer 06 Aug '07

06 Aug '07

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.

2 2

[PATCH] typos in sun/rmi/rmic/RemoteClass
by Christian Thalinger 05 Aug '07

05 Aug '07

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

1 0