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

[David P Grove]

Ian Rogers <ian.rogers@...> wrote on 02/20/2009 10:23:28 AM:
>
> 2009/2/20 David P Grove <groved@...>:
> > Also stepping back, I'd like to get a better understanding for thescenarios
> > 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.

Ok, thanks for clarifying the scenario in which you want to run Jikes RVM without relying on a standard thread library. At least for me that helps focus the discussion.

I don't see that there would ever be a need to bring back syswrap and all of its associated evil.  We didn't have syswrap until circa 2004 (part of the push to fully run Eclipse 2.x on Jikes RVM); we never had it on AIX; one doesn't need syswrap at all to run core regression tests with Jikes RVM (since they ran just fine on AIX all these years).

Pushing on the basic assumption of this thread a little bit more, do you really need green threads in Jikes RVM, or is that just the tack you are taking because it was there (and therefore expedient)?

Ignoring development cost for the moment, once the APIs being used by native threading stabilized to the point where we were running with native threads on both Harmony and GNU Classpath, would it be feasible to simply implement those APIs for your environment?  If so, would that be a more attractive option since such a thread implementation would naturally know more about your operating environment and could make better scheduling decisions and most likely do so more efficiently? It could also be used to execute something other than Jikes RVM in your environment. Then, consider cost:  what would it cost, could you leverage pieces of the old green threading implementation to help you (if you wanted to implement it in Java)?  If the cost/benefit works out, then consider timing: many of us have research projects that drop off the head for some period of weeks or months while we are finishing a piece of work.  Catching up to the latest release of Jikes RVM often means dealing with API changes. One does this at a good time when some piece of work is completed and your project members have time to devote to it.  There's a long history of this in MMTk.

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

[David P Grove]

I won't be online much this weekend so wanted to be summarize my current opinion on the main topics of this thread. All of this just my current opinion, not to be taken as more than that.

a) I don't see bringing back the old scheduler APIs or some minor variant of them as desirable. If it comes to a vote on that particular point over the weekend, count me as strongly against any such action.

b) The next release we make will be based on the current trunk and will be based on native threads. We are actually probably pretty close to a releasable system now using our normal criteria of what is passing/failing in the nightly test runs. I would prefer to get Harmony working first, but don't see this as critical since we were failing enough tests with Harmony before that I don't expect a large fraction of our user base is relying on Harmony as their primary class library provider. I also would set the end of March as a deadline for making a release. It has been too long since the last one already.

c) My current sense is that it seems very likely that some small delta off the current API is going to be workable for native threads on both GNU Classpath and Harmony. To the extent I have time to work on Jikes RVM, I am willing to spend it validating that thesis.

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

[Daniel Frampton]

Ok.. so I am going to ignore a lot of the discussion and make some
simple points :-)

* We currently directly call pthreads.

* From my reading hythreads is an interface that is designed to look
like a useful subset of pthreads for helping write a VM. It simply
does the job of matching supported operating systems to a common
pthreads-like interface. If you only wanted to support pthreads it
would be a giant no-op (but we don't).

* As with pthreads this means that hythreads sits below the level of
dealing with GC safety, etc. The JNI<->Java transition is relied on
for gc safety (all classlib uses of hythread are from JNI, naturally).

* Under harmony we can trivally call hythreads methods instead of
pthreads methods in most cases to remove the dependence on pthreads.
On linux this basically ends up as no change as hythread will just
bottom out in the same pthread call.

* The monitor in hythread is not intended to be a java monitor, it is
intended to be used as a low level primitive in exactly the same way
as pthreads condvars. On linux, hythread monitors are probably
implemented as a mutex/condvar pair. When we are supporting Harmony
and classpath in the head it might make more sense to change our
native call interface to have monitors more like hythread. It is an
absolutely trivial change from our current code... (instead of
creating a mutex and a cond, we create a 'monitor' that in our simple
version creates both and probably needs to allocate a 2 word struct to
hold the two words in C, and then use the 'right' one in the various
methods.)

Cheers,
Daniel.

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

[Filip Pizlo-2]

Thanks Daniel, that's a good summary.  I agree that it would be  
trivial to have HeavyCondLock allocate a system-specific, C "monitor"  
struct that may then be a mutex/cond pair for Classpath or just a  
Harmony monitor in the cast of Harmony.

-F



On Feb 20, 2009, at 6:09 PM, Daniel Frampton wrote:

> Ok.. so I am going to ignore a lot of the discussion and make some
> simple points :-)
>
> * We currently directly call pthreads.
>
> * From my reading hythreads is an interface that is designed to look
> like a useful subset of pthreads for helping write a VM. It simply
> does the job of matching supported operating systems to a common
> pthreads-like interface. If you only wanted to support pthreads it
> would be a giant no-op (but we don't).
>
> * As with pthreads this means that hythreads sits below the level of
> dealing with GC safety, etc. The JNI<->Java transition is relied on
> for gc safety (all classlib uses of hythread are from JNI, naturally).
>
> * Under harmony we can trivally call hythreads methods instead of
> pthreads methods in most cases to remove the dependence on pthreads.
> On linux this basically ends up as no change as hythread will just
> bottom out in the same pthread call.
>
> * The monitor in hythread is not intended to be a java monitor, it is
> intended to be used as a low level primitive in exactly the same way
> as pthreads condvars. On linux, hythread monitors are probably
> implemented as a mutex/condvar pair. When we are supporting Harmony
> and classpath in the head it might make more sense to change our
> native call interface to have monitors more like hythread. It is an
> absolutely trivial change from our current code... (instead of
> creating a mutex and a cond, we create a 'monitor' that in our simple
> version creates both and probably needs to allocate a 2 word struct to
> hold the two words in C, and then use the 'right' one in the various
> methods.)
>
> Cheers,
> Daniel.
>
> ------------------------------------------------------------------------------
> 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

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

[Ian Rogers (nabble)]

2009/2/21 Filip Pizlo <pizlo@...>:
> Thanks Daniel, that's a good summary.  I agree that it would be
> trivial to have HeavyCondLock allocate a system-specific, C "monitor"
> struct that may then be a mutex/cond pair for Classpath or just a
> Harmony monitor in the cast of Harmony.
>
> -F

And we lose simplicity and robustness.

Ian

> On Feb 20, 2009, at 6:09 PM, Daniel Frampton wrote:
>
>> Ok.. so I am going to ignore a lot of the discussion and make some
>> simple points :-)
>>
>> * We currently directly call pthreads.
>>
>> * From my reading hythreads is an interface that is designed to look
>> like a useful subset of pthreads for helping write a VM. It simply
>> does the job of matching supported operating systems to a common
>> pthreads-like interface. If you only wanted to support pthreads it
>> would be a giant no-op (but we don't).
>>
>> * As with pthreads this means that hythreads sits below the level of
>> dealing with GC safety, etc. The JNI<->Java transition is relied on
>> for gc safety (all classlib uses of hythread are from JNI, naturally).
>>
>> * Under harmony we can trivally call hythreads methods instead of
>> pthreads methods in most cases to remove the dependence on pthreads.
>> On linux this basically ends up as no change as hythread will just
>> bottom out in the same pthread call.
>>
>> * The monitor in hythread is not intended to be a java monitor, it is
>> intended to be used as a low level primitive in exactly the same way
>> as pthreads condvars. On linux, hythread monitors are probably
>> implemented as a mutex/condvar pair. When we are supporting Harmony
>> and classpath in the head it might make more sense to change our
>> native call interface to have monitors more like hythread. It is an
>> absolutely trivial change from our current code... (instead of
>> creating a mutex and a cond, we create a 'monitor' that in our simple
>> version creates both and probably needs to allocate a 2 word struct to
>> hold the two words in C, and then use the 'right' one in the various
>> methods.)
>>
>> Cheers,
>> Daniel.
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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
>

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

[Ian Rogers (nabble)]

2009/2/20 David P Grove <groved@...>:

> Ian Rogers <ian.rogers@...> wrote on 02/20/2009 10:23:28 AM:
>
>>
>> 2009/2/20 David P Grove <groved@...>:
>> > Also stepping back, I'd like to get a better understanding for
>> > thescenarios
>> > 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.
>
> Ok, thanks for clarifying the scenario in which you want to run Jikes RVM
> without relying on a standard thread library. At least for me that helps
> focus the discussion.
>
> I don't see that there would ever be a need to bring back syswrap and all of
> its associated evil.  We didn't have syswrap until circa 2004 (part of the
> push to fully run Eclipse 2.x on Jikes RVM); we never had it on AIX; one
> doesn't need syswrap at all to run core regression tests with Jikes RVM
> (since they ran just fine on AIX all these years).

Syswrap is pretty essential for AWT on Classpath. The 2.4 Jikes RVMs
mainly couldn't run AWT code until I fixed this.

> Pushing on the basic assumption of this thread a little bit more, do you
> really need green threads in Jikes RVM, or is that just the tack you are
> taking because it was there (and therefore expedient)?
>
> Ignoring development cost for the moment, once the APIs being used by native
> threading stabilized to the point where we were running with native threads
> on both Harmony and GNU Classpath, would it be feasible to simply implement
> those APIs for your environment?  If so, would that be a more attractive
> option since such a thread implementation would naturally know more about
> your operating environment and could make better scheduling decisions and
> most likely do so more efficiently?

In our environment the drivers are written in Java, there is no notion
of something below the RVM.

> It could also be used to execute
> something other than Jikes RVM in your environment. Then, consider cost:
>  what would it cost, could you leverage pieces of the old green threading
> implementation to help you (if you wanted to implement it in Java)?  If the
> cost/benefit works out, then consider timing: many of us have research
> projects that drop off the head for some period of weeks or months while we
> are finishing a piece of work.  Catching up to the latest release of Jikes
> RVM often means dealing with API changes. One does this at a good time when
> some piece of work is completed and your project members have time to devote
> to it.  There's a long history of this in MMTk.
>
> --dave

Right we'll fork. I'll make the fork public as there is a lot of
research out there hanging off green threads.

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