At 05:37 PM 6/6/00 -0400, Stephen Pair wrote:
>Right, I just thought the specification might have something to say about
>how OS threads are used, given that it could have a big impact on code
>portability...isn't Java code supposed to be portable?

As someone else noted, "supposed to be".  The Java spec is a little
underconstrained with respect to threads and thread scheduling and
preemption.

>The third option [language threads within NCPU OS threads] seems to
>be the most sensible...which VMs take that pproach?

As far as I know, Solaris "pthreads" are implemented in this
way, and the Java VM that I work on (BulletTrain, see
http://www.naturalbridge.com if you are interested) also does this
on Windows NT.  Everyone else, as far as I know, uses native threads
or "green" thread (many threads in a single OS thread).

>Could it be adopted by Squeak?

Don't know.  Don't know enough about Squeak to say for sure.

>If so, what kind of effort would it be?

I thought it was pretty hard (I read Moby Dick while I was
coding the worst of it).  Debugging it is very hard.
Note, we use an explicit safe-point system (compiler-inserted
polling) to ensure that threads cooperate, whether they like
it or not, and I think this was a help.  We also have
control of the generated code, so if we decided that needed
some tweak to make it all work, then the tweak duly appeared.
This is not necessarily possible in a compile-via-C world.
I think that some of the compile-time analysis that we do
to make this work well would be difficult to fit into the
Squeak world.

>What complications are there with that approach?

I'm not 100% sure you can derive the full benefits of it unless
you have control of your stacks.  We grow our own stacks as
necessary.  This means that we've got to maintain a strict
separation between "native" (C) stacks and "non-native" stacks,
since (at least in our implementation) we pick up the stacks
and move them around, and most C programs and C compilers don't
expect this to happen.

Regarding the overhead of Java locks -- most implementations that
I know of manage to stuff the "lock" information into less than
a word for each object for the usual case; that is, they generally
have two-word headers (one word for type info, the other word for
everything else).

One other thing to note -- we're not out for absolute portability
or absolute purity, so we're perfectly willing to write a few
hundred lines of C or assembly language if it will get the job
done quickly and efficiently.  If you intend to do this sort of
threaded runtime  "all in Squeak", then I wish you luck, but would
not bet on your success.



David Chase
chase at world.std.com
drchase at alumni.rice.edu
http://www.incompetentsoftwarehucksters.com