This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: user-space threads
"Boehm, Hans" <hans_boehm@hp.com> writes:
> I understand it is claimed to solve the 10K thread problem.)
How do they get around the L1/TLB cache thrash problem of having the
"working set" be 10,000 seperate memory pages, each with its own page
table entry (since the page above the stack must be write-protected)?
I propose to solve this with stack-sharing.
> I would be opposed to making a user-level threads package the
> default on any system that had another, more standard threads
> implementation,
Agreed. I'm definately not suggesting this as the default. However,
it could make multithreaded servers as fast as nonblocking-io,
singlethread servers. The big advantage is that the multithreaded
paridigm is far easier to write code for.
> I'm not sure how far you can really reduce maximum thread stack
> sizes,
I don't propose to decrease the total amount of stack used, but I do
propose to coagulate it all onto a single, contiguous set of pages in
order to maximize L1 and TLB cache effectiveness. This is widely
believed to be the biggest reason why high-performance thread
implementations are still slower than select()-based single-threaded
servers.
- a
--
"Through your rags I see your vanity" -- Socrates