This is the mail archive of the
mailing list for the Java project.
Re: Segment Register thread descriptor (was Re: Jv_AllocBytesChecked)
- To: Bryce McKinlay <bryce at albatross dot co dot nz>
- Subject: Re: Segment Register thread descriptor (was Re: Jv_AllocBytesChecked)
- From: Tom Tromey <tromey at redhat dot com>
- Date: 04 Jan 2001 21:41:29 -0700
- Cc: "'java-discuss at sources dot redhat dot com'" <java-discuss at sources dot redhat dot com>
- References: <140D21516EC2D3119EE700902787664401E3A7DC@hplex1.hpl.hp.com> <3A43F0C4.AB38213D@appnet.com> <3A4FCB17.E6743D67@albatross.co.nz> <3A4FE3C0.E1AEB2E2@albatross.co.nz> <firstname.lastname@example.org> <3A53CEB9.C056EE13@albatross.co.nz> <email@example.com> <3A551BD4.D2281469@albatross.co.nz>
- Reply-To: tromey at redhat dot com
>> 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.
Bryce> I don't think you understand the issue here.
Bryce> If we import the linuxthreads sysdeps, we can inline these into
Bryce> our monitor lock/release code, making it much faster. We'll
Bryce> also automatically get the definitions for these primitives on
Bryce> every platform that linuxthreads supports. If we don't, we'd
Bryce> have to waste time reimplementing the primitives ourselves for
Bryce> each architecture (or else use standard pthreads functions as
Bryce> fallback). Since there is presumably only one way to implement
Bryce> a correct compare-and-exchange on each architecture, the
Bryce> implementations will no doubt be copied directly from
Bryce> linuxthreads. At what point does this become a licensing
I honestly don't know. We can definitely ask about it though. Do you
want to do that? If not, I'll do it.