[email protected] wrote on 04/02/2012 11:05:42 PM:
> From: Martijn Verburg
> To: Da Vinci Machine Project
> Date: 04/02/2012 11:14 PM
> Subject: Re: Coroutines in JDK8++?
> Sent by: [email protected]
>
> Hi Mark,
> On 3 April 2012 00:40, Mark Roos wrote:
&
safepoints. Figure 4.4 in my master's thesis (see
below) gives an overview of what this code does.
p.s. I see you made it to Amazon
Serializable Coroutines for Java Virtual Machines: An efficient
implementation based on the HotSpot(TM) Java Virtual Machine
Yes, but don't bother buying it,
Hi Mark,
On 3 April 2012 00:40, Mark Roos wrote:
> Hi Martijn
>
> If the effort meets my needs I'll be there to help. My goal is a full
> implementation
> of Smalltalk on the JVM. One thing I need is the ability to manipulate a
> suspended
> thread from the object side. For this Lukas' work s
Hi Martizn
If the effort meets my needs I'll be there to help. My goal is a full
implementation
of Smalltalk on the JVM. One thing I need is the ability to manipulate a
suspended
thread from the object side. For this Lukas' work seems a good fit.
My concern is that (as John Rose points out )
access to the stack. I believe this in done during launch. If true is
there
an explanation of what this code does somewhere?
thanks
mark
p.s. I see you made it to Amazon
Serializable Coroutines for Java Virtual Machines: An efficient
implementation based on the HotSpot(TM) Java Virtual
> In this case I think the suitable thing to do would be to coordinate work
> around
> your existing patch via some sort of OSS project and look at all of the
> aspects
> that would need to be covered in order for it to be accepted into the
> OpenJDK.
> For example, a lot of thought will need to go
Hi Lukas/Charlie,
Basically we're trying to get more people involved in the OpenJDK as well
as
helping projects like coroutines get into a good shape for possible
inclusion into
the OpenJDK. This includes helping out with JEP and JSR processes as a
project matures.
In this case I thin
ecember, and people have been
> compiling and using it at least mid-February.
> It is quite experimental, but it's complete enough to prove the usefulness
> of coroutines on a JVM.
>
> One important step towards coroutines on Java is a JSR, I guess...
> There's a mailing
Hi,
I've last updated the coro patch beginning of December, and people have
been compiling and using it at least mid-February.
It is quite experimental, but it's complete enough to prove the
usefulness of coroutines on a JVM.
One important step towards coroutines on Java is a JS
f you have some spare cycles and are interested in joining in then
please let me know.
Cheers,
Martijn
On 1 April 2012 09:44, Mark Roos wrote:
> I was looking at the proposals for JDK8.9.10 and did not see any mention
> of coroutines/green threads.
>
> Are they flawed, not interesting, et
I was looking at the proposals for JDK8.9.10 and did not see any mention
of coroutines/green threads.
Are they flawed, not interesting, etc or just did not rise to the level of
getting
a bullet? Or maybe they did get the bullet.
mark
___
mlvm-dev
At 11:53 AM +0200 5/4/11, Lukas Stadler wrote:
>Hm - that seems weird.
>Could you perhaps do me a favour and check if both "coro.patch" and
>"coro-meth.patch" are being applied?
>
>I had to split off a part of the patch that has to be applied
>differently if the meth patches are present.
>So now it
is is a core JVM feature, so something under java.lang seems appropriate
>> in any case...
>>
>> java.lang.coroutine (or coro) is maybe too specific?
>>
>> How far off would it be to call coroutines "fibers" outright? Perhaps fiber
>> does not sufficie
Hm - that seems weird.
Could you perhaps do me a favour and check if both "coro.patch" and
"coro-meth.patch" are being applied?
I had to split off a part of the patch that has to be applied
differently if the meth patches are present.
So now it's either "coro-standalone.patch" and "coro.patch" o
At 5:42 PM +0200 5/3/11, Lukas Stadler wrote:
>Ah - since invokedynamic doesn't use the java.dyn package any more the
>necessary build infrastructure went missing... I just re-added it.
>One of the tests still fails, but at least it compiles...
Yes, now it compiles for me. Here's the coro test fai
ropriate in
> any case...
>
> java.lang.coroutine (or coro) is maybe too specific?
>
> How far off would it be to call coroutines "fibers" outright? Perhaps fiber
> does not sufficiently cover all uses of coroutines.
>
> I'll throw out java.lang.fiber as an option.
&g
r off would it be to call coroutines "fibers" outright? Perhaps fiber
does not sufficiently cover all uses of coroutines.
I'll throw out java.lang.fiber as an option.
java.lang.stack would cover the wider uses of stack-swapping, stack-memoizing,
and microthreading happening her
Ah - since invokedynamic doesn't use the java.dyn package any more the
necessary build infrastructure went missing... I just re-added it.
One of the tests still fails, but at least it compiles...
- Lukas
On 05/02/2011 05:27 PM, Stephen Bannasch wrote:
> I've uploaded a build of mlvm with coro en
I've uploaded a build of mlvm with coro enabled:
http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-mlvm-2011_05_02.tar.gz
but running these tests fail: jdk/test/java/dyn/CoroutineTest.java
#section:compile
--messages:(3/175)--
command: compile
/Users/stephen/de
On Apr 21, 2011, at 12:28 PM, Mark Roos wrote:
> If so do I have to do something to enable them?
>
> If not are they in b138?
>
> They look like a good fit for my Smalltalk processes
The coro stuff is probably a good fit for you.
The 292 work is probably stepping on coro's toes in the mlvm
At 12:28 PM -0700 4/21/11, Mark Roos wrote:
>Are Lucas' coroutines supported in the latest mac build?
>
>If so do I have to do something to enable them?
>
>If not are they in b138?
>
>They look like a good fit for my Smalltalk processes
Last time I tried includin
Are Lucas' coroutines supported in the latest mac build?
If so do I have to do something to enable them?
If not are they in b138?
They look like a good fit for my Smalltalk processes
mark
___
mlvm-dev mailing list
[email protected]
Le 08/04/2010 09:49, Christian Thalinger a écrit :
> On Wed, 2010-04-07 at 19:20 +0200, Lukas Stadler wrote:
>
>> I'm currently writing a paper about the coroutine implementation for
>> this year's PPPJ conference. That'll take up most of my time for the
>> next two weeks.
>>
> Hmpf. Tha
On Wed, 2010-04-07 at 19:20 +0200, Lukas Stadler wrote:
> I'm currently writing a paper about the coroutine implementation for
> this year's PPPJ conference. That'll take up most of my time for the
> next two weeks.
Hmpf. That reminds me that I promised to write one too about the JSR
292 implem
On Apr 7, 2010, at 10:55 AM, Charles Oliver Nutter wrote:
>> what I'd like to say is "if you want to apply coro.patch then
>> you need to exclude all other patches".
>> I suppose there's a simpler way to do that?
If you use only the single guard +coro you should get that effect.
Drop the other "
On Wed, Apr 7, 2010 at 12:20 PM, Lukas Stadler wrote:
> Wow, I didn't expect to instantly get that much feedback!
>
> I'm sorry, I should have updated the code examples to reflect the API
> changes I did last week.
>
> I'm currently writing a paper about the coroutine implementation for
> this yea
Wow, I didn't expect to instantly get that much feedback!
I'm sorry, I should have updated the code examples to reflect the API
changes I did last week.
I'm currently writing a paper about the coroutine implementation for
this year's PPPJ conference. That'll take up most of my time for the
nex
On Tue, Apr 6, 2010 at 11:16 AM, Lukas Stadler wrote:
> Today I toyed around a little bit with JRuby and coroutines.
>
> I modified JRuby to use my coroutine implementation and ran some
> fiber-microbenchmarks. The results are pretty good:
> http://classparser.blogspot.co
Ok, I'll broach the question: What would it take to get coroutines
into JDK7? Is it too late? Does it just need someone to lead a JSR?
Of all the features in Ruby 1.8.7 and 1.9, the one that scares me the
most is inbuilt coroutine support. We've so far managed to simulate
them ok wi
On Apr 6, 2010, at 8:07 PM, Stephen Bannasch wrote:
> I'm confused about how to interpret these two guards for coro.patch: '+coro'
> and '-/coro'
>
> What does the prefix '-/' signify?
/foo by local convention means "not foo". Therefore, -/foo is a double
negative. It may be needed (besides
If I set guards="buildable coro" I get patches that don't apply cleanly.
When I run: hg qguard -l in sources/hotspot
I see this for coro.patch:
coro.patch: +coro -/coro +/meth +/indy +/callcc +/inti +/dynopt +1e976d3fd820
-testable
I'm confused about how to interpret these two guards for coro.
At 6:16 PM +0200 4/6/10, Lukas Stadler wrote:
>Today I toyed around a little bit with JRuby and coroutines.
Kukas, that's exciting!
Building today with guards="buildable testable" seems to include the coro.patch
http://gist.github.com/358261
But I'm not able to successf
o we'd probably want
to have a CoroutineFiberLibrary that we can reflectively load when
coroutines are available, using the threaded version otherwise.
There's also another form of fibers for Ruby 1.8 mode that's currently
implemented mostly in Ruby called Generator, which works bas
Fabulous stuff. I should mention that our Ruby 1.9 mode still is in
pure-interpreted mode so once we get our JIT hooked up these numbers
should look even nicer!
-Tom
On Tue, Apr 6, 2010 at 11:16 AM, Lukas Stadler wrote:
> Today I toyed around a little bit with JRuby and coroutines.
&g
Oh my god, this is awesome. I'll respond with more later.
On Tue, Apr 6, 2010 at 11:16 AM, Lukas Stadler wrote:
> Today I toyed around a little bit with JRuby and coroutines.
>
> I modified JRuby to use my coroutine implementation and ran some
> fiber-microbenchmarks. The result
Today I toyed around a little bit with JRuby and coroutines.
I modified JRuby to use my coroutine implementation and ran some
fiber-microbenchmarks. The results are pretty good:
http://classparser.blogspot.com/2010/04/jruby-coroutines-really-fast.html
I know that the gains won't be near
And I'm almost exclusively interested in coro :)
On Thu, Mar 11, 2010 at 9:03 AM, Lukas Stadler wrote:
> Yes, the coro patch should be applied without continuations.
> It doesn't need any of the continuation functionality - maybe I should
> make that more clear in the series file...
> - Lukas
>
>
Yes, the coro patch should be applied without continuations.
It doesn't need any of the continuation functionality - maybe I should
make that more clear in the series file...
- Lukas
On 11.03.2010 12:58, Christian Thalinger wrote:
> On Wed, 2010-03-10 at 17:04 +0100, Lukas Stadler wrote:
>
>>
On Wed, 2010-03-10 at 17:04 +0100, Lukas Stadler wrote:
> Hi everybody!
>
> As you've probably seen I've pushed a new coroutine implementation into
> the repository.
I'm just rebasing the mlvm patches to the latest code drop and HotSpot's
coro.patch does not apply cleanly on top of the other pat
I'm planning on spending a bunch of time next week on MLVM, especially
invokedynamic updates for JRuby and trying out coroutines and tail
calls. So I'll let you know what I see :)
On Wed, Mar 10, 2010 at 10:04 AM, Lukas Stadler wrote:
> Hi everybody!
>
> As you've probabl
Hi everybody!
As you've probably seen I've pushed a new coroutine implementation into
the repository.
I've posted a few examples and precompiled binaries on my blog:
http://classparser.blogspot.com/2010/03/coroutines-for-java-status-update.html
Maybe someone wants to give it a t
Support millions of coroutines.
So if it's possible to have a choice, that sounds great, but if not, choose
a more scalable implementation if only one can be done. Making coroutines
effectively as cheap as other objects for managing state opens up their
usage, and it would also be competiti
Yes, the best will be to have the choice, i.e two different Java objects
or a way to select if you want to share the stack between coroutine or not.
Rémi
Attila Szegedi a écrit :
> As coroutines are often employed in situations where massive parallelism is
> desired, I believe that the ap
As coroutines are often employed in situations where massive parallelism is
desired, I believe that the approach that allows millions of them is the better
choice, if a single choice has to be made.
That said, if there is a meaningful way to have the programmer choose between
the two models
"traditional" implementations context switches are very cheap
(constant time), but at least 12-16 kb of memory and 16-32 kb of address
space is used per coroutine. This can exhaust 32-bit address space with
~5 coroutines. And in order to do something useful we might need
larger stack si
45 matches
Mail list logo
