« Return to Thread: [rvm-core] The future of the thread model, interactions with class libraries
Re: [rvm-core] The future of the thread model, interactions with class libraries
by Ian Rogers (nabble)
::
Rate this Message:
2009/2/19 David P Grove <groved@...>:
> 1) This really shouldn't involve a flame war or heated argument. In theory
> we are all adults and this is a purely technical discussion. Let's keep it
> that way. If on reading someone's email there appears to be a way to read it
> and get mad, try reading it again under the assumption that English is an
> ambiguous language, email a blunt instrument, and we're all professionals
> who don't want to indulge in flame wars because they reflect poorly on us as
> individuals and the project as a whole.
As a theoretical adult, I agree completely :-)
> 2) Before proposing solutions or writing any code, I'd like us to
> collectively take a few steps back and understand what the actual use cases
> for green threading are so we can figure out the best way to support them.
> In particular, I want to understand if it makes sense to support these
> "below" the "native thread" APIs instead of beside them. This is the
> approach we took in a project I was involved in [1] where we took J9 (which
> uses a port library abstraction that bears a very strong similarity to the
> one used by Harmony...) and ported it with minimal effort to a
> libraryOS/hypervisor without a pthread package by rolling our own threading
> library below J9's portlibrary abstraction. We felt that this resulted in a
> much better overall result since there was still only 1 scheduler, it was at
> the place where it could have all the information it needed to make the best
> possible decisions, and there were no changes required in the actual JVM
> code (including the JVM's locking code, implementation of sleep, etc).
I agree with taking steps back, and hope this e-mail exchange can be
used for this.
So, my understanding of your proposal would be that in
org.jikesrvm.scheduler we provide a thin veneer that punts everything
to syscalls. In the syscalls we implement greenthreads as C code,
pthreads with cond locks as C code or map to harmony style calls. Why
is writing everything as C code advantageous to Java code? It seems we
give up part of our metacircularity in this approach and also have to
reinvent all of the thread models.
Ian
> --dave
>
> [1]
> http://domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.vee2007.html
------------------------------------------------------------------------------
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
> 1) This really shouldn't involve a flame war or heated argument. In theory
> we are all adults and this is a purely technical discussion. Let's keep it
> that way. If on reading someone's email there appears to be a way to read it
> and get mad, try reading it again under the assumption that English is an
> ambiguous language, email a blunt instrument, and we're all professionals
> who don't want to indulge in flame wars because they reflect poorly on us as
> individuals and the project as a whole.
As a theoretical adult, I agree completely :-)
> 2) Before proposing solutions or writing any code, I'd like us to
> collectively take a few steps back and understand what the actual use cases
> for green threading are so we can figure out the best way to support them.
> In particular, I want to understand if it makes sense to support these
> "below" the "native thread" APIs instead of beside them. This is the
> approach we took in a project I was involved in [1] where we took J9 (which
> uses a port library abstraction that bears a very strong similarity to the
> one used by Harmony...) and ported it with minimal effort to a
> libraryOS/hypervisor without a pthread package by rolling our own threading
> library below J9's portlibrary abstraction. We felt that this resulted in a
> much better overall result since there was still only 1 scheduler, it was at
> the place where it could have all the information it needed to make the best
> possible decisions, and there were no changes required in the actual JVM
> code (including the JVM's locking code, implementation of sleep, etc).
I agree with taking steps back, and hope this e-mail exchange can be
used for this.
So, my understanding of your proposal would be that in
org.jikesrvm.scheduler we provide a thin veneer that punts everything
to syscalls. In the syscalls we implement greenthreads as C code,
pthreads with cond locks as C code or map to harmony style calls. Why
is writing everything as C code advantageous to Java code? It seems we
give up part of our metacircularity in this approach and also have to
reinvent all of the thread models.
Ian
> --dave
>
> [1]
> http://domino.research.ibm.com/comm/research_people.nsf/pages/dgrove.vee2007.html
------------------------------------------------------------------------------
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
« Return to Thread: [rvm-core] The future of the thread model, interactions with class libraries
| Free embeddable forum powered by Nabble | Forum Help |
