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

[Ian R. <ian...@ma...>]

So firstly the need for abstraction has been highlighted by getting
Harmony threads right, green threads is something else I want but I'm
not sure what percentage of the code in this direction will be made
public in the short term. Ideally we'd have a green thread
implementation on non-bare metal so that it can be kept in good shape.

2009/2/20 David P Grove <gr...@us...>:
> Also stepping back, I'd like to get a better understanding for the scenarios
> where you think it is desirable to apply green threading. This is going to
> impact what functions we need to support. Here are some possibilities I can
> think of, are one or more of these what is driving you, or have I missed a
> key scenario?
>
> (a) Running Jikes RVM on a platform that doesn't have a native threading
> layer. Some of the questions here would be:

This is our scenario.

> (1) Is the platform multi-core, so we need m-n, or is it single core, in
> which case n-1 is most likely what is actually needed.

Multi-core.

> (2) It would seem possible at least that you don't need syswrap and all of
> the other attempts to make blocking native code work with greenthreading in
> this scenario. If the platform doesn't have native threading, I'd speculate
> that it might not have native APIs like select, poll, etc. that we hijack.

We don't need syswrap, but to test green threads away from our effort
then syswrap may be necessary. However, syswrap shouldn't be brought
in for any of the native thread implementations.

> (b) Running Jikes RVM on a platform that has a native threading layer, but
> you want to run more Java threads than the native threading layer can
> efficiently support. This was the main original motivation for m-n threading
> in Jikes RVM. I think improvements in native threading layers since 1997
> have made this a significantly less compelling scenario. There are still
> cases where it might make sense, but they are fairly specialized.

This scenario doesn't apply to us.

> For what it's worth, I'm working on X10 now, and with the X10 1.7 runtime
> design, green threading is not an option we are pursuing for efficient
> implementation of asyncs.

Right, with the java.util.concurrent Executors framework the
efficiency point is pretty much gone.

> (c) Running Jikes RVM on a platform that has a native threading layer and
> running "standard" Java applications with thread counts that the native
> threading layer can efficiently support. (ie, every single one of the
> standard benchmarks used in typical research papers). I'm unconvinced that
> this scenario is worth supporting, but after spending so much time over the
> last 10 years trying to get it to work well, I admit I'm perhaps
> irrationally prejudiced against it.
>
> --dave

I'm not sure what you mean by this one, but as we don't have a native
thread layer this scenario doesn't apply.

Regards,
Ian