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

What I was proposing is (I think) more or less what Fil described as part of his longer note.

Suppose we take the sysCalls made at the "bottom" of the native threading layer as the specification of what the rest of Jikes RVM expects from its underlying thread abstraction. Pull those into a class/interface so that we can have multiple implementations, selecting one at build time just like we do for GCs in MMtk. Perhaps make minor cleanups, renamings, and generalizations.
(1) There's a default trivial implementation where those methods are implemented as sysCalls to C code that wraps pthread calls. That's native threading against GNU Classpath/pthreads.
(2) There's a default trivial implementation where those methods are implemented as sysCalls to C code that wraps Harmony threading APIs. That's native threading against Harmony/pthreads. Perhaps this is very close to (1) and is just some ifdefs in the C code. I haven't looked at the Harmony library enough to know.
(3) Same as (1) and (2), except for Open JDK.
(4) There's an implementation, most likely written in Java, that is not at all trivial where something functionally like the m-n threading we had before is provided. Perhaps some old green threading code can be re-used. A key question here is do you want n-1 or n-m. n-1 is significantly simpler to implement. This is really a question about use cases and target platforms. In theory we might want to have both n-1 and n-m.
(5) (In theory...the Libra project is over so I'm not motivated to go and write it) there's an implementation, written in C against the Libra library OS functions, which lets Jikes RVM run on a hypervisor partition without an OS underneath it at all.
(6) ...more options here...JNode?

The main point is that we avoid re-introducing scheduler APIs in the default case where we are running with native threading. Instead, green threading sits below the rest of the JVM and Jikes RVM as a whole can be oblivious to how those APIs are implemented. I believe this should yield a simpler and easier to maintain green threading layer than what we had before (which had 10+ years of evolution and multiple attempts to accommodate hostile native code embedded in it). I'm sure it will yield a simpler and easier to maintain native threading layer.

--dave

------------------------------------------------------------------------------
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