This is the mail archive of the
mailing list for the Java project.
RE: Segment Register thread descriptor (was Re: Jv_AllocBytesChec ked)
- To: "'drepper at cygnus dot com'" <drepper at cygnus dot com>, "Boehm, Hans" <hans_boehm at hp dot com>
- Subject: RE: Segment Register thread descriptor (was Re: Jv_AllocBytesChec ked)
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Mon, 8 Jan 2001 11:00:25 -0800
- Cc: tromey at redhat dot com, "'Bryce McKinlay'" <bryce at albatross dot co dot nz>, "'java-discuss at sources dot redhat dot com'" <java-discuss at sources dot redhat dot com>, "MOSBERGER, DAVID (HP-PaloAlto,unix3)" <davidm at hpl dot hp dot com>, Benjamin Kosnik <bkoz at redhat dot com>
Perhaps we should back up a little bit here. The fundamental question seem
to be whether it's worth trying to produce a library that encapsulates the
low level thread primitives needed by libgcj (both the GC and libjava),
libstdc++, and any other clients that want to join in.
The goals would be to:
1) Make it possible for clients to remain machine independent, though they
doing so will not be completely trivial.
2) The result should be correct on all supported platforms, and support for
as many platforms as possible. This means that we need to be able to fall
back to things like pthreads-based locking for platforms we don't understand
3) Get the performance close enough to optimal on common platforms, so that
people are willing to use it. (Initially, at least, reasonable performance
would require gcc-like asm support or platform-dependent (?) compiler
This would be a low-level library aimed mostly at implementors of other
libraries. It is not aimed at programmers writing their first multithreaded
code (who should stick to Java, pthreads, or something similar).
I would have liked to see it in the libc implementation, simply because I
would expect libc itself, and many of the higher level libraries to use it.
But it sounds like we should make it a separate entity.
As was pointed out by one of the other posters, there are some copyright
issues. We would like to be able to reuse at least the assembly sequences
that are currently in various other libraries. The license on the result
should be sufficiently liberal that it does not discourage use. I
personally believe that means that clients cannot be restricted to GPL'ed
code. As I read the Library GPL, it would be OK if and only if all inline
functions in the header file are less than 10 lines in length? (This could
probably be arranged ...) In such cases, the LGPL seems to be basically
equivalent to a Berkeley-style license? I would still prefer to use
something like the C++ STL license in this case, since it seems a lot
I think we agree that taking any of the exisiting implementations and
blessing it as the common library is not good enough. But it is important
to be able to selectively reuse the code, since none of us has access to
enough platforms to reproduce it.
> What would the thread register be used for? Is it a pointer, is it
> some other numeric value. Or as in the x86 case, what is if it is not
> really accessible? Similarly on Alpha where the thread pointer is
> retrieved through a (very fast) PAL code call.
So long as this is effectively part of the ABI (e.g. on Alpha?) I don't
it matters. The call in the library would expand to the PAL code call or
If the call depends on the thread library, then there are some hard choices
(which I would mostly push back to the client, with a reasonable default).
> > Right. But isn't that a fact of life for almost anything related to
> > threads?
> If there are ways which allow avoiding these pitfalls they should be
> taken. You are a bit too much in this corporate software development
> thinking. 99% of all the people writing free software have no access
> to more than one architecture. If the code they write is not right
> away usable by other (at least to some degree) it will not be picked
> up. This is why I said the usage of the new features should be
> fool-proof. Then the person writing the code will get it right.
I think you're giving to much credit to us corporate software developers.
In many cases, it's not easy for us to test on competitive hardware either,
though I do currently have the advantage that I can test on different HP
hardware. But I think I understand the problem. I think in this case, the
problem is fundamentally unsolvable; things have to work somewhat
differently on different hardware. But I think there's a potential for
greatly improving matters, by reducing the number of implementations of this
low level synchronization code to one, and making it possible for clients to
test both the lock-based and lock-free implementation on the same platform
(assuming it supports the lock-free option).
> > > Not a problem. Associate a lock with the whole array.
> But of course
> > > you can say this is not good and you want to lock
> individual blocks in
> > > the array. This plays again in the area of not having to
> define too
> > > many interfaces. Everybody wants something different.
> > Which is why I would prefer to let the user declare the locks.
> Not in all cases. This is an optimization which certainly is not
> always necessary.
OK. I think it's fine to provide it both ways.