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

So firstly here is the Harmony thread API:

http://harmony.apache.org/externals/vm_doc/html/hythread_8c.html

I have problems with pretty much everything that's been said here:

Dave> 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."

in the planning for 3.1 I stated that I don't see Classpath as our
long term class library, assuming it in the thread model, to me,
appears wrong.

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

this doesn't fit Harmony. In the current threading code we assume cond locks.

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

So this appears to be creating a task for people working off green
threads to create a new green thread implementation. The expedient
thing is to work off where we were (sufficient to run all
applications, X10 and the majority of the JSR166 TCK).

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

But we inherently get a non-metacircular implementation and have to
reinvent the green thread world.

Fil, look at the Harmony thread API and you'll see what my point is. I
agree that there are changes elsewhere in the scheduler API and with
reintroducing green threads and a harmony model they should be adhered
to. What I disagree with is exposing the cond locks in the scheduler.

Daniel> The previous implementation of Harmony was not ready for
production use. From the tests we were running it never supported
multiple processors, and when running with a single processor had a
significant number of failures. Obviously moving to a system without
green threads makes running with a single processor no longer
possible. This was a well understood problem, and work on Harmony to
fix this issue was deliberately delayed until after native threads was
implemented.

I agree, we have been running against and leading Classpath
development for a while. Harmony support was at a good level. We ran
SPEC JVM 2008, which I see as essential for a research virtual
machine. There is much research that can be done on a single core.

Daniel> This relates to a significant issue that I don't think was
adequately addressed at the time. The announcement of our initial
compatibility/support for the Harmony libraries was premature, and I
know made a lot of the core team uncomfortable. Such announcements
have the potential to significantly affect the credibility of Jikes
RVM, and should not be made without some consultation within the core
team. What we claim to support officially in releases of JikesRVM has
a direct impact on everyone working on the project.

So this is highly irritating. If you have concerns:
1) e-mail me, and/or
2) open JIRAs, there's a whole place for these in the Harmony support, and/or
3) mail the core mailing list
Saying that the Harmony support was announced prematurely should
really have been stated at the time, when it could have been
rectified. Saying it now is just ridiculous.

In terms of credibility, it is far far more important for our
credibility that we run on a class library that will give enough
support to at a least run major benchmark suites. In this case SPEC
JVM 2008.

I would dearly love help with the Harmony implementation, so far
Alexey has been the only contributor.

Daniel> I think it is clear that we all want to work toward
compatibility with Harmony (and possibly OpenJDK) but we need to do so
carefully.

As we were already compatible with Harmony, I don't know why we're
taking a view that we're not.

Daniel> I have left aside my thoughts on the low level technical
detail here; it is important to take a step back from that and solve
the strategic issues first.

I agree. We either have a minimalist interface or something where we
have multiple configurations. I need multiple configurations and if I
can't do that against the trunk I will have to do my own thing.

In terms of premature decisions, I think merging Fil's code with the
trunk was premature. We should have worked these issues out first. We
should have closed the JIRAs on RVM-91 first. We should have asked the
core list before the merge, first.

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