This is the mail archive of the java-discuss@sources.redhat.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Segment Register thread descriptor (was Re: Jv_AllocBytesChecked)


Tom Tromey wrote:

> That is the issue.  I imagine we'd have to get RMS to sign off on the
> exception (if the code is in glibc).  This seems unlikely.

Well, if that is that case then case silly licensing trivialities are
once again preventing us from writing the best possible code.

> How long will it be until these are the most common systems?  If it is
> going to happen soon anyway, then I'm not too conerned.

I don't think you understand the issue here. Importing the sysdeps
directory from linuxthreads would allow us to implement faster locking by
not having to call both pthread_self() and pthread_mutex_lock() for every
monitor lock. There are two primitives that are important here - the
compare-and-exchange thread synchronization primitive, and current thread
lookup (which on many architectures is as simple as loading from a
register).

If we import the linuxthreads sysdeps, we can inline these into our
monitor lock/release code, making it much faster. We'll also
automatically get the definitions for these primitives on every platform
that linuxthreads supports. If we don't, we'd have to waste time
reimplementing the primitives ourselves for each architecture (or else
use standard pthreads functions as fallback). Since there is presumably
only one way to implement a correct compare-and-exchange on each
architecture, the implementations will no doubt be copied directly from
linuxthreads. At what point does this become a licensing violation?

regards

  [ bryce ]



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]