This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: Jv_AllocBytesChecked (Was: What is wrong with Vector?)
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: Re: Jv_AllocBytesChecked (Was: What is wrong with Vector?)
- From: Jeff Sturm <jeff dot sturm at appnet dot com>
- Date: Fri, 22 Dec 2000 19:24:36 -0500
- CC: "'tromey at redhat dot com'" <tromey at redhat dot com>, "'java-discuss at sources dot redhat dot com'" <java-discuss at sources dot redhat dot com>
- References: <140D21516EC2D3119EE700902787664401E3A7DC@hplex1.hpl.hp.com>
"Boehm, Hans" wrote:
> Thus I think we're stuck with hashing to find monitors. But that in itself
> is cheap. On X86, it's completely dominated by the cost of finding your own
> thread id, which you need to allow recursive monitor entry. (Ulrich was in
> the process of changing linuxthreads to keep the thread id in a segment
> register. Anyone know if that's making progress?)
The last time I looked at this, there were kernel changes needed to set
the FS (or was it GS?) segment register per task. The code in
linuxthreads can be enabled once the kernel is ready... I have no idea
if 2.4 will handle this yet.
But other architectures should benefit from hash synchronization as
well. Currently, linuxthreads for Alpha uses PAL_rduniq to determine
the thread ID, which should be significantly faster than examining stack
registers.
Jeff