[rvm-core] The future of the thread model, interactions with class libraries

Hi,

so the preliminaries:

1) native threads should be the Jikes RVM default!
2) great work Fil!

There is a desire to have green threading again (at least from me) and
to get Harmony running again, so let's play out some examples of how
to say support the sleep operation with different thread models
(ignoring cleaning up the arguments and throwing any exceptions that
may have been flagged while we were asleep):

greentheads - take the running thread, put some time information into
it (or a proxy - I forget) and then put it on the waiting queue,
schedule other work

pthreads - take the thread, get a pthread cond lock, do a syscall to
do a timed wait on the pthread cond lock

harmony threads - take the thread, call through to a harmony interface
that abstracts the sleep

so what abstractions do we need: things that are processor local (ie.
processors we used to have these, they should probably be an interface
to make native threads efficient), a singleton thing to ask global
questions to like how many locks are there (ie. the scheduler we used
to have), different thread model implementations. I see the packages
of:

org.jikesrvm.scheduler

this is the interface to the rest of the world, nothing externally
should be accessing packages beneath here

org.jikesrvm.scheduler.greenthreads - the implementation for
greenthreads (queues, etc.) that we had for GNU Classpath, to fully
support this with Harmony requires creating a DLL wrapper. Support for
Classpath requires the syswrap hack.

org.jikesrvm.scheduler.nativethreads.pthreads - Fil's work on
providing a full pthread model, cond locks won't be exposed above
here.

org.jikesrvm.scheduler.nativethreads.harmony - As with the original
native thread goal, just punt to a native thread library, ie Harmony
threads

There is likely to be a chance to share things, like queues, between
the pthread and green thread code, we can therefore have a utility
directory. We should probably not have a lot of different lock or
other implementations in the top-level scheduler package, they can be
pushed down into other packages.

I believe this proposal is controversial as it's bringing back the
interface as it was around 3.0.1. I don't propose we copy and paste
that code, but the structure will look like it from the outside. Feel
free to flame me about why the old interface was the stupidest thing
ever as I would like to shake out what are myths and realities (it's
not a secret that the old thread model wasn't 100% complete).

Can we implement the Harmony code a different way? Yes, I will try
this in the short-term. We can implement the Harmony threads using the
Apache Portable Runtime. This is diving under the feet of the harmony
thread implementation. I believe it is best in the long-term we use
the Harmony interface for Harmony, as it means we are abdicating
responsibility for threading to Harmony and Harmony can give us
compatibility on all the platforms Harmony supports (we are a Java VM,
we should run on all platforms as Java is portable). I could also try
emulating pthread cond locks with Harmony's Java like monitors, but
this would be vile.

What will break? AIX ;-) Nothing should break, as this change is just
*adding functionality*. The build can be configured to use the models
that are complete for the particular architecture. Long-term I'd
expect Harmony native threads to be the default. Green threads has a
user base. Native pthreads for Classpath will be there for the curious
and platforms like AIX where Harmony may not build straight away.

What about OpenJDK? Depending on the abstraction it will probably
closely resemble either Harmony or pthreads, my belief is probably
more like pthreads. Having the flexibility in our model should mean
little work in matching OpenJDKs thread model to ours.

What does this mean for 3.1? I think the thread model is in a state of
flux and it's not in the place it should be. I'd be tempted to make
the next release 3.0.2 and bring back the green thread model
temporarily (maybe keep native threads on the trunk and revert them on
the 3.0.2 branch). I think the current code exposes too many pthread
internals and this will be a portability issue for users interfacing
with the thread library. Ideally the changes above can be written
before the next release and then it could be 3.1, this may be pushing
things (there are still many outstanding pthread JIRAs without the
addition of native threads for Harmony and incorporating green threads
- it would be nice to see more progress on the pthread JIRAs for
low-hanging things like method names).

So I am off to get all my clothes asbestos lined. This is deliberate,
not just flippant, I want everyone who has a complaint about this idea
to complain. I feel with the current pthread code going into the trunk
I complained and wasn't listened to. I hope I will listen to other
people's pov and we can get the abstraction that fits everyone's
requirements (or learn why this is a mistake).

Regards,
Ian

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core