Re: merging the classpath threadlocal changes

[Andrew John Hughes <gnu_andrew at member dot fsf dot org>]

On 17:07 Sun 28 Sep     , Matthias Klose wrote:
> Andrew John Hughes schrieb:
> > 2008/9/24 Matthias Klose <doko@ubuntu.com>:
> >> this is a pending patch for some files which are not used in libgcj, and the
> >> files are shadowed except for one new file. Just merging the patch does result
> >> in a build failure, because libgcj picks up this one new file. can makemake.tcl
> >> blacklist this, or should libgcj just get an empty file/class?
> >>
> >>  Matthias
> >>
> > 
> > What is the build failure? I assume the new ThreadLocalMap (or
> > whatever it's called)
> > is referring back to ThreadLocal, though the map itself is unused.
> > Maybe gcj's version
> > could support the needed methods without using the map itself?
> 
> Didn't save the build logs. Afaicr these were differences in return and
> parameter types for some thread related classes.

Here's the patches just committed (forgot to add the new files at first...).
The failures you were seeing were due to the ThreadLocalMap requiring a hash
value from java.lang.Thread.  Also InheritableThreadLocal is not shadowed,
so the changes in that were causing a build error due to a method that's
in ThreadLocalMap but not WeakIdentityHashMap (inherit).

Although in the best case scenario GCJ uses system thread-local storage
via POSIX threads, it still uses the Classpath map solution in a number of
situations.  First of all, it is always used for set (the native version
is stored first, followed by a call to internalSet(Object)). For get(),
it will only be used if POSIX threads are unavailable on build (the
working implementation is #ifdef on _POSIX_PTHREAD_SEMANTICS),
initialisation fails or the value can't be retrieved.  So although the map
is not usually used as much by gcj, the Classpath version still has a minor
effect (and is thus not as irrelevant as it may first have seemed).

With this patch, I ported the hash value changes to GCJ's java.lang.Thread
and updated internalGet, internalSet and internalRemove to use ThreadLocalMap
instead.  The latter can be dropped if necessary, but it seems sensible to
try and stay close to Classpath where possible.

2008-09-28  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* classpath/java/lang/ThreadLocalMap.java,
	* java/lang/ThreadLocalMap$Entry.h,
	* java/lang/ThreadLocalMap.h,
	* lib/java/lang/ThreadLocalMap.class,
	* lib/java/lang/ThreadLocalMap$Entry.class:
	Add the new files for the ThreadLocal patch.

2008-09-28  Andrew John Hughes  <gnu_andrew@member.fsf.org>

	* classpath/ChangeLog,
	* classpath/java/lang/InheritableThreadLocal.java,
	* classpath/java/lang/Thread.java,
	* classpath/java/lang/ThreadLocal.java:
	Merge Daniel Frampton's ThreadLocal patch.
	* gcj/javaprims.h: Updated.
	* java/lang/Thread.h: Regenerated.
	* java/lang/Thread.java:
	Replace WeakIdentityHashMap with ThreadLocalMap.
	(getThreadLocals()): Likewise.
	* java/lang/ThreadLocal.h: Regenerated.
	* java/lang/ThreadLocal.java:
	(computeNextHash()): New method.
	(ThreadLocal()): Initialise fastHash.
	(internalGet()): Updated to match Classpath's get().
	(internalSet(Object)): Likewise for set(Object).
	(internalRemove()): Likewise for remove().

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

Attachment: 0.98_merge-06.diff
Description: Text document

Attachment: 0.98_merge-07.diff
Description: Text document