[kaffe] CVS kaffe (guilhem): Updated regression tests. Updated some
FAQ.
Kaffe CVS
cvs-commits at kaffe.org
Wed Jun 15 08:41:08 PDT 2005
PatchSet 6646
Date: 2005/06/15 15:35:24
Author: guilhem
Branch: HEAD
Tag: (none)
Log:
Updated regression tests. Updated some FAQ.
* test/regression/Makefile.am: Added DoubleIEEE.
* test/regression/Makefile.in: Regenerated.
* test/regression/ProcessClassStop.java,
test/regression/ProcessClassLockTest.java: Increased the timeout
value.
* WHATSNEW: Updated.
* FAQ/FAQ.pthreads: Updated. Thread.stop() deprecated.
* FAQ/FAQ.locks: Updated locks algorithm.
Members:
ChangeLog:1.4172->1.4173
WHATSNEW:1.42->1.43
FAQ/FAQ.locks:INITIAL->1.6
FAQ/FAQ.pthreads:1.2->1.3
test/regression/Makefile.am:1.94->1.95
test/regression/Makefile.in:1.212->1.213
test/regression/ProcessClassLockTest.java:1.4->1.5
test/regression/ProcessClassStop.java:1.14->1.15
Index: kaffe/ChangeLog
diff -u kaffe/ChangeLog:1.4172 kaffe/ChangeLog:1.4173
--- kaffe/ChangeLog:1.4172 Wed Jun 15 12:39:53 2005
+++ kaffe/ChangeLog Wed Jun 15 15:35:24 2005
@@ -1,5 +1,21 @@
2005-06-15 Guilhem Lavaux <guilhem at kaffe.org>
+ * test/regression/Makefile.am: Added DoubleIEEE.
+
+ * test/regression/Makefile.in: Regenerated.
+
+ * test/regression/ProcessClassStop.java,
+ test/regression/ProcessClassLockTest.java: Increased the timeout
+ value.
+
+ * WHATSNEW: Updated.
+
+ * FAQ/FAQ.pthreads: Updated. Thread.stop() deprecated.
+
+ * FAQ/FAQ.locks: Updated locks algorithm.
+
+2005-06-15 Guilhem Lavaux <guilhem at kaffe.org>
+
* test/regression/DoubleIEEE.java: New testcase for strict IEEE
computation.
Index: kaffe/WHATSNEW
diff -u kaffe/WHATSNEW:1.42 kaffe/WHATSNEW:1.43
--- kaffe/WHATSNEW:1.42 Mon May 30 21:16:01 2005
+++ kaffe/WHATSNEW Wed Jun 15 15:35:26 2005
@@ -6,6 +6,7 @@
GNU classpath's system class loader. This improves support
for the Java Extension Mechanism and the Java security
model.
+* Force double precision on x86 FPU for Linux OS.
What's New in Kaffe 1.1.5
------------------------------------------------------
===================================================================
Checking out kaffe/FAQ/FAQ.locks
RCS: /home/cvs/kaffe/kaffe/FAQ/FAQ.locks,v
VERS: 1.6
***************
--- /dev/null Sun Aug 4 19:57:58 2002
+++ kaffe/FAQ/FAQ.locks Wed Jun 15 15:41:08 2005
@@ -0,0 +1,210 @@
+Here is a brief summary of locking in Kaffe.
+
+There are several layers to the locking abstractions in Kaffe.
+Ideally these layers are collapsed by the compiler.
+
+Java Object Locks
+=================
+
+ files: kaffe/kaffevm/locks.[hc]
+
+ lockObject(H_java_lang_Object*)
+ unlockObject(H_java_lang_Object*)
+
+These should only be used for Java object monitors. They just take a
+pointer to the Java object. The intent is that if we ever create a
+facility to log the execution of all monitorenter/exit bytecodes,
+entries and exits of synchronized methods and JNI MonitorEnter/Exit
+primitives, we'll be able to do it by tweaking this function. These
+functions are implemented as a thin layer over the VM-internal locks
+(See the next section).
+
+NOTE: these are functions, and must remain so, since their addresses
+are taken in some engines.
+
+The wait and signal functions on Java objects map directly to the wait
+and signal functions in the VM-internal locks (see the next section).
+XXX There should probably be waitObject(), signalObject(), and
+broadcastObject() interfaces. Currently the waitCond(), signalCond()
+and broadcastCond() interfaces are just invoked directly.
+XXX should be a slowUnlockObjectIfHeld(), too (for stack unwinding due
+to an exception).
+
+NOTE: Two other functions are part of this interface:
+ slowLockObject(H_java_lang_Object*, void*);
+ slowUnlockObject(H_java_lang_Object*, void*);
+these are used by some engines when the inlined "fast lock" fails.
+See the "Kaffe Fast Locking" section, below. There need not be
+"slow" versions of the wait/signal/broadcast functions.
+
+
+VM-internal object locks
+========================
+
+ files: kaffe/kaffevm/locks.[hc]
+
+ types: iLock
+
+ lockMutex lockStaticMutex
+ unlockMutex unlockStaticMutex
+ waitCond waitStaticCond
+ signalCond signalStaticCond
+ broadcastCond broadcastStaticCond
+
+There are two flavors of VM-internal locking interfaces. One for
+dynamic locks (left column) and one for static locks (right column).
+Dynamic locks are generally used to protect VM-internal dynamic structures
+(e.g., classes). Static locks are generally global locks (e.g., the
+gc lock or finalizer lock) or locks that need a specific out-of-order
+initialization.
+
+The VM must use its own internal locks for most internal state, to
+avoid race conditions with arbitrary Java code that uses object locks.
+(For example on threads and classes, there are both logical Java-level
+locks, and VM-internal locks).
+
+There is one instance of using the VM-internal interfaces to lock a
+Java-level object: when JIT-compiling a method, a lock on its Class is
+held. Logging such a lock via the lockObject() interface would be
+unexpected: it would only be logged when the JIT was in use.
+Moreover, it is not mandated nor directed by any of the Java monitor
+facilities. Therefore, this case uses the VM variant, and so should
+similar cases that ever come up.
+
+These locks are recursive. Despite the disjoint names, the same iLock
+object supports both the lock/unlock and wait/signal/broadcast
+interfaces.
+
+The non-static interfaces are a bit odd in that the argument passed in
+must be a pointer to a struct with a "lock" field. The lock field
+must be an iLock pointer. The static interfaces take a pointer to a
+iLock pointer.
+
+To avoid the use of building heavy locks you must only lock once. If
+you exceed that limit a heavy lock is allocated and kept in memory
+until the lock is destroyed. The new implementation(*) heavy lock is
+actually not that slow as it must only acquire the heavy lock by
+putting a 1 into some field and then increment the lock counter when
+called recursively.
+(*) As of 2005-03-11
+
+Threading System Synchronization Primitives
+===========================================
+
+The VM-internal locking scheme is implemented on top of the primitives
+provided by the Kaffe threading system. The underlying threading
+system has two choices for implementing the lowest layer of locking in
+Kaffe. First is the Ksem interface which provides a semaphore
+primitive on which the Kaffe run-time bases its "heavy locks". (See
+the "Kaffe Fast Locking" section below.) The second option is to
+implement the "jmutex/jcondvar" interface (which is just used to fill
+out a default Ksem implementation.)
+
+A. The Ksem interface:
+---------------------
+
+ files: kaffe/kaffevm/ksem.h, threading system lock files
+
+ types: Ksem
+
+ ksemInit(sem)
+ ksemGet(sem,timeout)
+ ksemPut(sem)
+ ksemDestroy(sem)
+
+The Ksem is a binary semaphore, and need not be recursive. The Ksem
+is initialized to 0 (in semaphore-speak this means the resource is not
+available). ksemGet() can timeout, thus it returns a boolean
+indication of whether it acquired the semaphore or not. The timeout
+is specified in milliseconds.
+
+As a side-effect of Kaffe's fast locking scheme, there is a one-to-one
+mapping between Ksem and threads. Also, all Ksem's are dynamically
+allocated when a thread is created and all are initialized before
+being used.
+
+
+B. The jmutex/jcondvar interface:
+--------------------------------
+
+ files: kaffe/kaffevm/ksem.h, threading system lock files
+
+ types: jmutex, jcondvar
+
+ jmutex_initialize
+ jmutex_lock
+ jmutex_unlock
+ jmutex_destroy
+
+ jcondvar_initialize
+ jcondvar_signal
+ jcondvar_wait
+ jcondvar_destroy
+
+At this layer, mutexes are distinct from condition variables, though
+the condition variable wait and signal are provided with an associated
+mutex. A jmutex should not be recursive. Kaffe guarantees that a
+jmutex and jcondvar are used in a strict pair (see the implementation
+of Ksem). Broadcast is never used on the condition variable.
+
+
+Kaffe Fast Locking
+==================
+
+Kaffe has a fast locking scheme that minimizes the cost of uncontended
+locks and non recursive locks. The fast locking scheme is implemented between VM-internal
+locking layer and the threading system's locking primitives. The
+basic idea is that a "heavy" lock is not allocated unless there is
+some contention for it. Note that once an heavy lock has been
+allocated the lock remains heavy until it is destroyed. The
+implementation takes into account one observation: all pointers to heap-allocated objects in
+Kaffe are at least 4-byte aligned, thus making the bottom two bits of
+every pointer available. However, we cannot rely on the stack frame to
+see recursive locks as some (un)locking may happen at different
+level. For example, JNI requires that we have JNI_MonitorEnter and
+JNI_MonitorExit: those two functions are called by an external library
+to (un)lock an object however it is absolutely not guaranteed that the
+stack pointer will be the same for the two calls. So recursion cannot
+be fully optimized.
+
+Here is some weak pseudo-code to explain the heavy lock algorithm.
+
+if lock field is NULL
+ set lock field to current thread's "id"
+else
+ /* we are going to acquire an heavy lock */
+ if lock field bottom bit is not set
+ /* This is a thin lock */
+ if it is a static lock
+ try to acquire the heavy lock
+ success => initialize it and put it in the lock
+ field
+ failure => exit the outer if to "a".
+ else it is not a static lock
+ /* It is a dynamic lock and we must allocate the
+ * heavy */
+ Allocate and initialize a new heavy lock
+ try to put it in the lock field
+ endif
+ endif
+a:
+
+ /* lock field is an heavy lock */
+ b: try to acquire the heavy lock
+ if it fails wait a semaphore event
+ loop to "b".
+
+
+When the heavy lock is released the algorithm increase the semaphore
+counter only if some thread is waiting for the semaphore. The checking is done
+using an atomic counter which gives the number of threads waiting on the given
+semaphore.
+
+Jason Baker <jbaker at cs.utah.edu>
+Jun 29, 1999
+updated by Alexandre Oliva <oliva at lsd.ic.unicamp.br>
+Sept 18, 1999
+updated by Patrick Tullmann <tullmann at cs.utah.edu>
+Mar 17, 2000
+updated by Guilhem Lavaux <guilhem at kaffe.org>
+Mar 3, 2005
Index: kaffe/FAQ/FAQ.pthreads
diff -u kaffe/FAQ/FAQ.pthreads:1.2 kaffe/FAQ/FAQ.pthreads:1.3
--- kaffe/FAQ/FAQ.pthreads:1.2 Sun Oct 17 21:04:20 1999
+++ kaffe/FAQ/FAQ.pthreads Wed Jun 15 15:35:27 2005
@@ -12,11 +12,12 @@
Limitation
----------
-* We currently don't support fork/exec/wait under pthreads.
-
* Certain I/O operations cannot be interrupted.
-* We do not support asynchronous exceptions via Thread.stop()
+* We do not support asynchronous exceptions via Thread.stop(). This will never
+be implemented as this is a buggy part of the Java specification and its use
+has been deprecated by GNU Classpath developers. The reason is that it can leave
+the VM is an unknown state.
SMP support
-----------
Index: kaffe/test/regression/Makefile.am
diff -u kaffe/test/regression/Makefile.am:1.94 kaffe/test/regression/Makefile.am:1.95
--- kaffe/test/regression/Makefile.am:1.94 Sun Apr 24 09:57:44 2005
+++ kaffe/test/regression/Makefile.am Wed Jun 15 15:35:27 2005
@@ -63,7 +63,8 @@
LongNeg.java \
FPUStack.java \
NegativeDivideConst.java \
- divtest.java
+ divtest.java \
+ DoubleIEEE.java
## Test strings
TEST_STRINGS = \
Index: kaffe/test/regression/Makefile.in
diff -u kaffe/test/regression/Makefile.in:1.212 kaffe/test/regression/Makefile.in:1.213
--- kaffe/test/regression/Makefile.in:1.212 Sat May 14 21:47:10 2005
+++ kaffe/test/regression/Makefile.in Wed Jun 15 15:35:27 2005
@@ -411,7 +411,8 @@
LongNeg.java \
FPUStack.java \
NegativeDivideConst.java \
- divtest.java
+ divtest.java \
+ DoubleIEEE.java
TEST_STRINGS = \
Str.java \
Index: kaffe/test/regression/ProcessClassLockTest.java
diff -u kaffe/test/regression/ProcessClassLockTest.java:1.4 kaffe/test/regression/ProcessClassLockTest.java:1.5
--- kaffe/test/regression/ProcessClassLockTest.java:1.4 Mon May 30 21:16:11 2005
+++ kaffe/test/regression/ProcessClassLockTest.java Wed Jun 15 15:35:29 2005
@@ -23,7 +23,7 @@
new Thread() {
public void run() {
try {
- Thread.sleep(2500);
+ Thread.sleep(10000);
System.out.println("sorry, you timed out");
System.exit(-1);
} catch (Exception e) {
Index: kaffe/test/regression/ProcessClassStop.java
diff -u kaffe/test/regression/ProcessClassStop.java:1.14 kaffe/test/regression/ProcessClassStop.java:1.15
--- kaffe/test/regression/ProcessClassStop.java:1.14 Thu Jun 2 17:35:51 2005
+++ kaffe/test/regression/ProcessClassStop.java Wed Jun 15 15:35:29 2005
@@ -33,7 +33,7 @@
Thread wd = new Thread() {
public void run() {
try {
- Thread.sleep(3000);
+ Thread.sleep(10000);
System.out.println("sorry, you timed out");
System.exit(-1);
} catch (Exception e) {
More information about the kaffe
mailing list